AIプログラミング実践ガイド：従来型コーディングから AI 協働へ

過去かこ半年はんとしで、私が個人こじんで構築こうちくし、納品のうひんしたいくつかのプロジェクトでは、要件ようけんの整理せいり、実装じっそう、テスト、デプロイから、その後ごの本番ほんばん環境かんきょうでの問題もんだい修正しゅうせいやリファクタリングまで、具体的ぐたいてきなコーディング作業さぎょうの大部分だいぶぶんを AI に任まかせました。

その中には業務ぎょうむプロジェクトもあれば、内部ないぶツールもあります。経験けいけんしたことも、ただ「ページを1つ作つくる」といった単純たんじゅんなものではなく、要件ようけん変更へんこう、インターフェース連携れんけい、テスト、デプロイ、障害しょうがい、ロールバック、そして継続けいぞく的てきなイテレーションまで、一連いちれんの流ながれを通とおして経験けいけんしました。実際じっさいにやり切きってみて、ますますはっきりしたことがあります。AI プログラミングがもたらす最大さいだいの変化へんかは、「コード生成せいせいがより速はやくなる」ことではなく、エンジニアの仕事しごとの重心じゅうしんが移うつりつつあることです。

これまでなら必かならず自分じぶんで現場げんばに入はいって1行ぎょうずつ打うち込こむ必要ひつようがあったことの多おおくは、いまでは Agent に任まかせられます。しかしその一方いっぽうで、要件ようけんの分解ぶんかい、コンテキストの整理せいり、プロセスの制約せいやく、結果けっかの検証けんしょうは、むしろ以前いぜんより重要じゅうようになっています。あなたはもはや、ただコードを書かいているだけではありません。AI が継続けいぞくして安定あんてい的てきに働はたらける工学こうがく的てきなシステムを設計せっけいしているのです。

この記事きじは、「人はもうコードを書かく必要ひつようがない」と証明しょうめいしたいわけではありません。また、AI を何なんでもできるブラックボックスとして描えがきたいわけでもありません。むしろ、これは段階だんかい的てきな実践じっせんのまとめに近ちかいものです。AI が実際じっさいに日常にちじょうの開発かいはつフローに入はいってきたとき、エンジニアは自分じぶんの働はたらき方かたをどのように再構成さいこうせいすべきなのか、どこに投資とうしする価値かちがあり、どこでつまずきやすいのかを整理せいりするものです。

エンジニアの役割やくわりを再定義さいていぎする

最初さいしょ、AI プログラミングの核心かくしんは「プロンプトをどれだけうまく書かけるか」だと思おもっていました。けれど、あとになって、それは表面ひょうめんにすぎないと分わかりました。

本当ほんとうに成果物せいかぶつに影響えいきょうするのは、たいていプロンプトの一文いちぶんそのものではなく、あなたが物事ものごとをきちんと整理せいりできているかどうかです。

要件ようけんは十分じゅうぶんに明確めいかくなところまで分解ぶんかいされているか
制約せいやくと境界きょうかいははっきり書かかれているか
プロジェクトの構造こうぞうとルールは Agent が理解りかいできるようになっているか
納品のうひんの前まえに、完全かんぜんな検証けんしょうの閉とじたループがあるか

だから、エンジニアの中心的ちゅうしんてきな仕事しごとは、「機能きのうを直接ちょくせつ実装じっそうすること」から「タスクシステムを設計せっけいすること」へと移うつりつつあります。

かつて私わたしたちがもっとも注目ちゅうもくしていたのは、このコードをどう書かくか、このインターフェースをどう呼よび出だすか、この bug をどう直なおすか、でした。いま、より一般的いっぱんてきになっている問いといは、こうしたものです。

このタスクはどう分解ぶんかいすべきか
どの制約せいやくを先さきに置おかなければならないか
Agent にどの文脈ぶんみゃくを渡わたす必要ひつようがあるか
どの情報じょうほうはチャットで補足ほそくするのではなく、Agent に自動じどうで取得しゅとくさせるべきか
どのようなツールとフローで最後さいごを支ささえる必要ひつようがあるか

だからこそ、多おおくの人ひとがある錯覚さっかくを持もちます。AI を使つかい始はじめたころはとても驚おどろくほどすごいと感かんじるのに、タスクが複雑ふくざつになると制御せいぎょできなくなり始はじめる、という錯覚さっかくです。モデルが突然とつぜんだめになったわけではありません。工学こうがく的てきな問題もんだいは消きえておらず、ただ「実装じっそうの問題もんだい」から「組織そしきの問題もんだい」へと変かわっただけなのです。

別べつの言いい方かたをすれば、エンジニアはますますシステム設計者せっけいしゃに近ちかづいています。コードはいまも重要じゅうようです。しかし、それはもはや唯一ゆいいつの主戦場しゅせんじょうではありません。あなたが設計せっけいする必要ひつようがあるのは、「AI が簡単かんたんには道みちを外はずれない」ための環境かんきょうです。文脈ぶんみゃくをどう整理せいりするか、ドキュメントをどこに置おくか、フローをいつ起動きどうするか、結果けっかをどう検証けんしょうするか。これらが、AI が最終的さいしゅうてきに安定あんていして納品のうひんできるかどうかを決きめます。

Agent で Agent をレビューする

AI が大量たいりょうにコードを生成せいせいし始はじめると、新あたらしいボトルネックがすぐに現あらわれました。人間にんげんの review が追おいつかなくなったのです。

以前いぜんは、チームの 1 日にちあたりのコード増分ぞうぶんは比較的ひかくてき制御せいぎょしやすく、人間にんげんが diff を見みるだけでも、なんとか耐たえられました。いまは、Agent が 1 回かいでいくつものファイル、数十すうじゅうの関数かんすう、さらにテストやドキュメントまでまとめて変更へんこうできるため、人間にんげんの review 負荷ふかは急きゅうに大おおきくなります。人ひとが review できないということではありません。ただ、人間にんげんの注意力ちゅういりょくは希少きしょうなリソースであり、無限むげんに拡大かくだいできるものではないのです。

そこで私わたしはその後ご、自動じどう review フローを作つくりました。Agent が提出ていしゅつの前まえにまず第一だいいちラウンドのチェックを行おこない、さらに別べつの Agent がクロスレビューを行おこなう、というものです。人間にんげんは依然いぜんとして最終さいしゅう決定権けっていけんを持もちますが、すべての初期しょきスクリーニングを背負せおうことはなくなります。

このことの価値かちは、ただ「時間じかんを節約せつやくする」だけではありません。より重要じゅうようなのは、review を「注意力ちゅういりょくで無理むりやり耐たえるもの」から、「規模きぼに応おうじて運用うんようできるフロー」へと変かえることです。人間にんげんが見落みおとしやすい問題もんだい、たとえば境界きょうかいブランチ、例外れいがいパス、命名めいめいとロジックの一貫性いっかんせいなどは、Agent review の中なかでは、むしろ事前じぜんに露出ろしゅつしやすくなります。

もちろん、ここにはとても重要じゅうような境界きょうかいがあります。私わたしは Agent review を「人間にんげんの review を置おき換かえる」理由りゆうとして扱あつかったことはありません。それはむしろ、品質ひんしつを前段ぜんだんでフィルタする層そうのようなものです。機械きかいで先さきに振ふるい落おとせるものは、すべての問題もんだいを最後さいごに人間にんげんへまとめて背負せおわせるべきではありません。

もしコードを Agent が書かいたのなら、review もできるだけ Agent に第一だいいちラウンドを担になわせるべきです。これは人間にんげんの代替だいたいではなく、人間にんげんの注意力ちゅういりょくをより重要じゅうような判断はんだんに残のこすためです。たとえば、ビジネスロジックが正ただしいか、アーキテクチャの方向性ほうこうせいが妥当だとうか、長期的ちょうきてきな技術的負債ぎじゅつてきふさいを持もち込こんでいないか、といった判断はんだんです。

Agent に読よめるアプリケーションにする

コード生成せいせいのボトルネックが下さがると、もうひとつ、より現実的げんじつてきな問題もんだいが浮うかび上あがってきます。検証けんしょうです。

多おおくのチームは、AI プログラミングの難むずかしさは「書かくこと」にあると思おもっていますが、本当ほんとうに難むずかしいのは「それが正ただしく書かけていると確認かくにんすること」です。アプリケーションの実行結果じっこうけっか、ログ、監視指標かんししひょう、エラー情報じょうほうをすべて人力じんりきで見みるしかないなら、結局けっきょく、全体ぜんたいの流ながれは人工じんこう QA で詰つまってしまいます。

だから後のちに、私わたしがとくに重視じゅうしするようになったことのひとつが、アプリケーションを Agent に読よめるようにすることでした。

ここでいう「読よめる」とは、ページをレンダリングしてモデルにちらっと見みせる、という意味いみではありません。Agent が、アプリケーション実行後じっこうごのフィードバックを体系的たいけいてきに読よみ取とり、理解りかいできるようにすることです。たとえば：

UI の状態じょうたいに変化へんかがあったか
コンソールにエラーが出でていないか
API の戻もどり値ちが期待きたいどおりか
ログに例外れいがいスタックがないか
重要指標じゅうようしひょうに明あきらかな異常いじょうが出でていないか

これらの情報じょうほうを Agent が安定あんていして取得しゅとくできるようになると、検証けんしょうの工程こうていは「人ひとがページを見張みはってポチポチ操作そうさする」ものから、「Agent が独立どくりつして一通ひととおりの自己じこテストと切きり分わけを行おこなえる」ものへと進化しんかします。これは、Agent がすべてのテストを必かならず代替だいたいできるという意味いみではありません。多おおくの反復的はんぷくてきな検証作業けんしょうさぎょうに、ようやく自動化じどうかの土台どだいができるということです。

多おおくの場合ばあい、AI を本当ほんとうに制限せいげんしているのは「コードを書かけないこと」ではなく、「書かいた後あとの結果けっかが見みえないこと」です。だから、コードを AI に書かけるようにするだけでは、問題もんだいの半分はんぶんしか解決かいけつしていません。アプリケーションを AI に読よめるようにしてこそ、開発かいはつ、検証けんしょう、障害対応しょうがいたいおうをつなげられる可能性かのうせいが生うまれます。

AGENTS.md は目録もくろくであって、説明書せつめいしょではない

コンテキスト管理かんりは、AI プログラミングが「使つかえる」から「使つかいやすい」へ進すすむための鍵かぎです。

私わたしたちが最初さいしょに踏ふんだ、とても典型的てんけいてきな落おとし穴あながありました。すべてのルールを、ひとつの巨大きょだいな AGENTS.md に詰つめ込こもうとしたのです。ところが、プロジェクトが少すこし複雑ふくざつになっただけで、このやり方かたはほぼ必かならず破綻はたんすることがすぐにわかりました。

理由りゆうはとても単純たんじゅんです。

コンテキストウィンドウは希少きしょうなリソースであり、大おおきなファイルは本当ほんとうに重要じゅうような情報じょうほうを押おしのけてしまう
なんでも書かき込こむことは、重点じゅうてんがないことと同おなじ
大だいは小しょうを兼かねるようなルールファイルは、非常ひじょうに速はやく腐化ふかし、保守ほしゅコストがとても高たかい
単一たんいつの巨大きょだいファイルでは、鮮度せんどチェック、所有権しょゆうけん管理かんり、自動じどう検証けんしょうが難むずかしい

その問題もんだいは、ただ「長ながすぎる」ことだけではありません。すべてを書かいておけば Agent が自然しぜんと賢かしこくなる、という錯覚さっかくをチームに生うませてしまうことです。しかし実際じっさいは、その正反対せいはんたいです。情報じょうほうを積つみ上あげれば積つみ上あげるほど、Agent はシステム構造こうぞうを理解りかいするのではなく、局所的きょくしょてきなパターンマッチングをしているだけになりがちです。

その後ご、私わたしたちはやり方かたを変かえました。AGENTS.md を説明書せつめいしょではなく、目録もくろくとして扱あつかうようにしたのです。

それがすることは、3 つだけです。

Agent に、このリポジトリの大おおまかな構造こうぞうを伝つたえる
中核ちゅうかくとなるエントリポイントと、重要じゅうような規約きやくの場所ばしょを示しめす
Agent が、docs/ やコードリポジトリの中なかで本当ほんとうに保守ほしゅされるべき内容ないようを読よみに行いけるように導みちびく

このやり方かたの利点りてんは明快めいかいです。第一だいいちに、AGENTS.md 自体じたいを簡潔かんけつに保たもてるため、長期的ちょうきてきに腐化ふかしにくくなります。第二だいにに、本当ほんとうの知識ちしきをあるべき場所ばしょに置おき、業務ぎょうむにもっとも近ちかい人ひとが保守ほしゅできます。第三だいさんに、Agent が得えるのは、ひとかたまりに混まざったルール文ぶんではなく、地図ちずです。

Agent に渡わたすべきものは、1000 ページの手引書てびきしょではなく、一枚いちまいの地図ちずです。本当ほんとうに長期ちょうきにわたって有効ゆうこうな知識ちしきは、規約きやく文書ぶんしょ、設計せっけい文書ぶんしょ、インターフェース文書ぶんしょ、そしてコードそのものに蓄積ちくせきされるべきであり、ひとつの総合そうごうエントリファイルがすべてを解決かいけつしてくれると期待きたいすべきではありません。

なぜ AI にはプロンプトだけでなくツールチェーンが必要ひつようなのか

多くの人ひとが AI プログラミングを始はじめたばかりのころ、もっとも自然しぜんなやり方かたは「プロンプトに頼たよる」ことです。これは個人こじん、小ちいさなタスク、短みじかい処理しょり経路けいろの場面ばめんではまったく問題もんだいありません。

しかし、タスクが複雑ふくざつになり始はじめたり、チーム協業きょうぎょうの段階だんかいに入はいったりすると、プロンプトだけに頼たよるやり方かたはすぐに限界げんかいにぶつかります。

その理由りゆうは、プロンプトは本質的ほんしつてきに一回いっかい限かぎりのものですが、エンジニアリングが必要ひつようとするのは、再利用さいりようでき、協業きょうぎょうでき、統制とうせいできる能力のうりょくだからです。今日きょうある会話かいわの中なかでうまく説明せつめいできたとしても、明日あした、別べつの人ひと、別べつのリポジトリ、別べつの Agent が同おなじ品質ひんしつを再現さいげんできるとは限かぎりません。

その後あと、私はひとつのことをますます確信かくしんするようになりました。AI にチーム開発かいはつへ本当ほんとうに参加さんかさせたいなら、能力のうりょくを「個人こじんのその場ばの対応たいおう」から「チームのツールチェーン」へ引ひき上あげなければなりません。

成熟せいじゅくしたツールチェーンは、少すくなくとも次つぎのようなことを解決かいけつする必要ひつようがあります。

Agent が現在げんざいの会話かいわだけを見みるのではなく、外部がいぶシステムに接続せつぞくできるようにする
チームの制約せいやくを、口頭こうとうでの注意ちゅういに頼たよるのではなく、繰くり返かえし実行じっこうできるようにする
高頻度こうひんどのフローを、毎回まいかい手作業てさぎょうするのではなく、自動じどうで起動きどうできるようにする
有効ゆうこうな方法論ほうほうろんを、蓄積ちくせきし、再利用さいりようし、配布はいふできるようにする

だからこそ、私はその後あと、「より長ながいプロンプトをどう書かくか」にはますます注意ちゅういを向むけなくなり、むしろ「能力のうりょくをどう組織そしきするか」に重点じゅうてんを置おくようになりました。プロンプトは依然いぜんとして重要じゅうようですが、それはどちらかといえばその場ばの指揮しきです。本当ほんとうに上限じょうげんを決きめるのは、底層ていそうに再利用さいりようできるインフラがあるかどうかです。

Plugin から Marketplace へ：チームの能力のうりょくを再利用さいりようできる資産しさんにする

これらの能力のうりょくを本当ほんとうにチーム協働きょうどうへ入いり込こませるために、私は Plugin という視点してんから全体ぜんたいの体系たいけいを理解りかいすることに、より慣なれています。

Plugin は、ひとつのパッケージ単位たんいだと考かんがえられます。それは特定とくていのひとつのツールではなく、接続せつぞく能力のうりょく、制約せいやく、自動化じどうか、そして方法論ほうほうろんを組くみ合あわせた、インストールでき、アップグレードでき、レビューできるチーム能力のうりょくパッケージです。

この角度かくどから見みると、完全かんぜんな Plugin はたいてい四よっつの層そうを含ふくみます。

MCP：接続せつぞくの問題もんだいを解決かいけつし、Agent がシステム、ドキュメント、環境かんきょうを読よめるようにする
Rules：制約せいやくの問題もんだいを解決かいけつし、チーム規範きはんを統一とういつして実行じっこうできるようにする
Hooks：起動きどうの問題もんだいを解決かいけつし、適切てきせつなタイミングでフローが自動じどうで発生はっせいするようにする
Skill：方法ほうほうの問題もんだいを解決かいけつし、「どうすべきか」を再利用さいりようできるフローとして蓄積ちくせきする

この四よっつの層そうのうち、私がもっとも重要じゅうようだと思おもうのは MCP と Skill です。

MCP は、Agent が現実げんじつ世界せかいに触ふれられるかどうかを決きめます。接続せつぞくがなければ、Agent は「チャット式しきの開発かいはつ」にとどまるしかありません。書かき出だしたものがどれほどそれらしくても、実際じっさいのコンテキストから離はなれやすくなります。

Skill は、Agent がどう進すすめるべきかを知しっているかどうかを決きめます。接続せつぞくだけがあり、方法ほうほうがなければ、Agent はまだ「ツールは使つかえるが、フローは安定あんていしない」状態じょうたいにとどまります。どこにドキュメントがあり、どこにタスクがあり、どこにログがあるかは知しっていても、それらの情報じょうほうを得えたあとに、どの順序じゅんじょで動うごくべきかは分わかっていません。

Rules と Hooks の役割やくわりも重要じゅうようです。前者ぜんしゃは制約せいやくを固定化こていかする役割やくわりを担にない、後者こうしゃはこれらの能力のうりょくを実際じっさいのワークフローに埋うめ込こむ役割やくわりを担にないます。制約せいやくがなければ、チームのスタイルはぶれます。起動きどうがなければ、多くのよいフローも最後さいごには「知しっているが、できない」に戻もどってしまいます。

さらに一歩いっぽ上うえへ進すすむと、Marketplace になります。

Plugin が「能力のうりょくをうまくパッケージする」ことを解決かいけつするものだとすれば、Marketplace が解決かいけつするのは「能力のうりょくを外そとへ出だす」ことです。その意味いみは、さらに新あたらしい概念がいねんを導入どうにゅうすることではなく、チームがすでに蓄積ちくせきした能力のうりょくを、規模きぼをもってインストールし、再利用さいりようし、ガバナンスできるようにすることです。ここまで来きてはじめて、AI ツールチェーンは、もはや一部いちぶの熟練じゅくれんユーザーの私的してきなツールボックスではなく、本当ほんとうに組織そしき能力のうりょくのレベルへ入はいれるようになります。

ケース：オープンソースの Skill フレームワークで工程こうてい方法ほうほうを支ささえる

プロジェクト内ないの能力のうりょくを自分じぶんで蓄積ちくせきするだけでなく、私は長期ちょうきにわたって、オープンソースの Skill フレームワークを使つかい、工程こうてい方法ほうほうを支ささえています。Superpowers は、とても典型的てんけいてきな例れいです。GitHub コミュニティで高たかい注目ちゅうもくを集あつめており、すでにかなり完整かんせいな Skill 体系たいけいも蓄積ちくせきされています。

私がそれを好すきなのは、Skill の数かずが多おおいからではなく、多くの「よい工程こうてい実践じっせん」を、口頭こうとうの助言じょげんから明確めいかくなフローへ変かえているからです。

たとえば、こうした環節かんせつです。

手てを動うごかす前まえに、まず要求ようきゅうと設計せっけいをしっかり考かんがえる
設計せっけいを実行じっこう可能かのうな小ちいさなタスクへ分解ぶんかいする
隔離かくりされた環境かんきょうで実装じっそうを進すすめ、メインのワークスペースを汚染おせんするリスクを下さげる
書かき終おえたあとには、口頭こうとうで「完了かんりょうした」と宣言せんげんするのではなく、かならず検証けんしょうする
並行へいこうに進すすめるのに適てきした場面ばめんでは、複数の Agent で役割やくわりを分担ぶんたんして進すすめる

こうしたことは、以前いぜんもできなかったわけではありません。ただ、かなり個人こじんの自覚じかくに依存いぞんしていました。経験けいけんの十分じゅうぶんなエンジニアならそうすべきだと知しっていますが、忙いそがしくなったり、チーム規模きぼが大おおきくなったりすると、フローはすぐに劣化れっかしがちです。Skill フレームワークの価値かちはここにあります。こうした行動こうどうを「提案ていあん」から「デフォルトの動作どうさ」へ変かえるのです。

この種しゅのフレームワークが本当ほんとうに価値かちをもつ部分ぶぶんは、「どれだけ多おおくの技わざを提供ていきょうしているか」ではなく、チームがもともと経験けいけんと自覚じかくに頼たよっていた工程こうてい習慣しゅうかんを、安定あんていして再利用さいりようできるシステムへ変かえることです。

それはまた、私にひとつのことを思おもい出ださせます。AI ツールそのものは、過度かどに神格化しんかくかされやすいものです。しかし、本当ほんとうに差さを生うむのは、しばしばモデルではなく、仕事しごとの方法ほうほうを蓄積ちくせきできているかどうかです。モデルはどんどん強つよくなれますが、方法論ほうほうろんがなおもすべて現場げんばの即興そっきょうに頼たよっているなら、品質ひんしつは最終的さいしゅうてきにやはり漂流ひょうりゅうしてしまいます。

完全かんぜんな AI 開発かいはつの閉とじたループ

上うえの能力のうりょくをつなげて考かんがえると、私は今いま、AI 開発かいはつを単発たんぱつの効率化こうりつかツールではなく、完全かんぜんな閉とじたループとして理解りかいすることに、より慣なれてきています。

比較的ひかくてき安定あんていした流ながれは、たいてい次つぎのようになります。

まず問題もんだいをはっきり考かんがえ、目標もくひょう、制約せいやく、境界きょうかいを明確めいかくにする
タスクをより小ちいさな実行じっこう単位たんいに分解ぶんかいする
Agent に隔離かくりされた環境かんきょうで実装じっそうを完了かんりょうさせる
文書ぶんしょ、タスク、ログ、インターフェースなどの外部がいぶ文脈ぶんみゃくを接続せつぞくする
テスト、review、ログ、実行じっこう結果けっかで検証けんしょうする
最後さいごに、マージ、リリース、または継続けいぞくしてイテレーションするかを決きめる

これは「要件ようけんを AI に投なげて、コードをひと塊かたまり吐はき出だすのを待まつ」ことではなく、むしろ循環じゅんかんシステムに近ちかいものです。

この閉とじたループがもたらす直接ちょくせつの利点りてんは、ただ速はやいだけでなく、より安定あんていしていることにもあります。

開発かいはつ段階だんかいで、不足している文脈ぶんみゃくや制約せいやくを見みつけやすくなる
連携れんけい試験しけんの段階だんかいで、手作業てさぎょうの持もち運はこびに頼たよるのではなく、外部がいぶ情報じょうほうを接続せつぞくしやすくなる
自己じこ検証けんしょうの段階だんかいで、Agent により多おおくの反復的はんぷくてきな検証けんしょう作業さぎょうを担になわせることができる
納品のうひん段階だんかいで、文書ぶんしょ、状態じょうたい、変更へんこう説明せつめいをまとめて収束しゅうそくさせやすくなる

本当ほんとうに持続じぞく可能かのうな効率こうりつは、閉とじたループから生うまれるのであって、ある一回いっかいの驚おどろくような生成せいせい結果けっかから生うまれるのではありません。

さらに重要じゅうようなのは、この閉とじたループが逆ぎゃくにエンジニアの働はたらき方かたを作つくり変かえていくことです。機械的きかいてきな実装じっそうに時間じかんを使つかうことはますます少すくなくなり、境界きょうかいを設計せっけいし、情報じょうほうを整理せいりし、リスクを確認かくにんし、結果けっかを検証けんしょうすることに、ますます多おおくの時間じかんを使つかうようになります。これは仕事しごとが減へったということではなく、仕事しごとが「コーディングという肉体にくたい労働ろうどう」から「工学こうがくシステムの設計せっけい」へと変かわったということです。

AIプログラミング落おとし穴あなガイド

最後さいごに、事前じぜんに注意ちゅういしておく価値かちがいちばん高たかいと思おもう落おとし穴あなをいくつか話はなします。

1. 最初さいしょにルールを決きめないと、後あとはすべて負債ふさいになる

プロジェクト最初さいしょのパターンは、AIによってすばやく複製ふくせいされます。最初さいしょの数千すうせん行ぎょうのコードにおける構造こうぞう、命名めいめい、制約せいやく、ディレクトリが安定あんていしていなければ、その後ごの成果物せいかぶつはたいてい、これらの問題もんだいを拡大かくだいするだけです。AIは増幅器ぞうふくきです。よいパターンは増幅ぞうふくされ、悪わるいパターンも同おなじように増幅ぞうふくされます。

2. 長ながい対話たいわは資産しさんではなく、たいてい見みえない負債ふさいである

だいたい十数じゅうすう〜二十にじゅうラウンドを過すぎると、Agentは初期しょきの意思いし決定けっていと衝突しょうとつしはじめやすくなります。急きゅうに賢かしこさを失うしなったのではなく、コンテキストがすでに漂流ひょうりゅうしているのです。大おおきなタスクでは意識的いしきてきに新あたらしい会話かいわを開ひらき、以前いぜん確認かくにんした結論けつろんを明確めいかくに参照さんしょうするべきです。多おおくの手戻てもどりは、モデルが悪わるいからではなく、人間にんげんが「対話たいわが続つづいていること」を「一貫性いっかんせいが続つづいていること」と勘違かんちがいするからです。

3. 「完了かんりょうした」は、本当ほんとうに完了かんりょうしたという意味いみではない

AIは一見いっけん完全かんぜんに見みえる答こたえを出だすのがとても得意とくいですが、それは本当ほんとうに実行じっこうが通とおった、検証けんしょうが完了かんりょうした、ということを意味いみしません。境界きょうかいケース、例外れいがいパス、タイムアウト処理しょり、並行へいこう処理しょりの問題もんだいは、やはり明確めいかくに検証けんしょうする必要ひつようがあります。「それが完了かんりょうしたと言いった」ことを頻繁ひんぱんに信しんじはじめた瞬間しゅんかん、あなたはすぐにバグを後続こうぞくのフローへ持もち込こむことになります。

4. 重要じゅうようなロジックは必かならずdiffを見みる

機能きのうテストだけではすぐに見みえない問題もんだいもありますが、diffの中なかではとても明白めいはくに見みえることがあります。重要じゅうような変更へんこうであるほど、変更へんこうレビューを完全かんぜんに省略しょうりゃくしてはいけません。とくにデータフィールド、フォールバックロジック、権限けんげん判定はんてい、時間じかん処理しょりのような箇所かしょでは、AIはつい手癖てくせで、一見いっけん合理的ごうりてきだが実際じっさいには危険きけんな変更へんこうを入いれてしまいがちです。

5. アーキテクチャを凝こりすぎない

複雑ふくざつなマルチAgent編成へんせい、過剰かじょうな役割やくわり設定せってい、重おもすぎるメタルールシステムは、見みた目めには強力きょうりょくそうでも、実際じっさいの保守ほしゅコストはたいてい高たかくなります。ほとんどの場合ばあい、シンプルで、明確めいかくで、組くみ合あわせ可能かのうな能力のうりょく設計せっけいのほうが信頼しんらいできます。ひとつのSkillで解決かいけつできることなら、先さきに派手はでな総合そうごう制御せいぎょシステムを導入どうにゅうするべきではありません。

6. 一人ひとりで回まわせることは、チームで回まわせることを意味いみしない

個人こじんの効率こうりつ向上こうじょうと、チームの効率こうりつ向上こうじょうは別物べつものです。本当ほんとうに難むずかしいのは、全員ぜんいんが同おなじ規範きはん、ツール、プロセスを共有きょうゆうし、さらにプロジェクトの進化しんかに合あわせて継続的けいぞくてきに更新こうしんできるようにすることです。一人ひとりが経験けいけんで支ささえられる問題もんだいは、チームではたいてい協業きょうぎょうの中なかで拡大かくだいされます。

7. すべての問題もんだいにLLMが必要ひつようなわけではない

決定的けっていてきに処理しょりできることは、決定的けっていてきなプログラムで解決かいけつすればよいのです。AIは、理解りかい、生成せいせい、要約ようやく、計画けいかくのような、本当ほんとうにそれを必要ひつようとする場所ばしょで使つかうべきであり、すべての操作そうさをLLMに積つみ上あげるべきではありません。多おおくの「AI化か」方案ほうあんが最終的さいしゅうてきにコストが高たかく、効果こうかが低ひくくなるのは、本来ほんらいなら固定こていで書かくべきフローまで、無理むりやりモデルの推論すいろんに押おし込こんでいるからです。

まとめ：AIプログラミングは、より速はやくコードを書かかせるものではない

この半年はんとしを振ふり返かえると、ひとつのことがますます確信かくしんに変かわってきました。AIプログラミングにおけるもっとも重要じゅうような変化へんかは、「より速はやくコードを打うてる」ようにすることではなく、エンジニアに、工学こうがくの中なかで本当ほんとうに重要じゅうような部分ぶぶんへ、より多おおくの精力せいりょくを戻もどさせることです。

つまり、次つぎの3つです。

コンテキストを設計せっけいする
制約せいやくを設計せっけいする
検証けんしょうを設計せっけいする

これらは、手書てがきでコードを書かいていた時代じだいにも重要じゅうようでしたし、AIが開発かいはつに参加さんかするようになってからは、なおさら重要じゅうようになります。

技術ぎじゅつは加速かそくしていますが、工学こうがくの本質ほんしつは変かわっていません。要件ようけんは明確めいかくであるべきで、境界きょうかいははっきりしているべきで、構造こうぞうはきれいであるべきで、検証けんしょうは堅実けんじつであるべきです。AIが増幅ぞうふくしてくれるのは、システム全体ぜんたいの能力のうりょくです。だから最終的さいしゅうてきに得えられるものは、ただの「より多おおくのコード」ではなく、あなたが設計せっけいしたその工学こうがくの方法論ほうほうろんそのものなのです。

もし今いまのAIプログラミングに対たいする理解りかいを一言ひとことで要約ようやくするなら、こうです。それはエンジニアを「より速はやいプログラマー」に変かえるものではなく、エンジニアを「より強つよいシステム設計者せっけいしゃ」へと押おし上あげるものです。コンテキスト、フロー、制約せいやく、検証けんしょうをよりうまく組織そしきできる人ひとほど、AIをデモや短期的たんきてきな驚おどろきにとどめず、本当ほんとうの生産性せいさんせいへと組くみ込こめる可能性かのうせいが高たかくなります。