AIにコードを書かせるとき、つい「全部読めば賢くなるはず」と思いがちです。
でも元記事が言うのは、失敗の原因は“コードを書けないこと”ではなく、“間違った文脈を読んでしまうこと”にある、というかなり本質的な指摘です。これ、地味ですがかなり重要だと思います。
この記事の主張はシンプルです。
AIに「リポジトリ全部を読んで」と渡すのは、親切そうに見えて実は危ない。
代わりに、その作業に必要な情報だけをまとめた「context package」を渡したほうがよい。
ここでいう context は「状況」や「前提情報」のことです。
AIは文章やコードを読めますが、どれが古くて、どれが正しくて、どれが例外なのか は自動で完璧に判断できません。そこを人間が設計してあげる必要がある、という話ですね。
人間でも、資料が多すぎる会議って混乱しますよね。
「READMEにはこう書いてあるのに、古い設計メモには別のことが書いてある」「昔のチャットログに、もう捨てた案が残っている」みたいなことは普通に起きます。
AIも同じで、いや、むしろAIのほうがその影響を受けやすいです。
元記事では、AIが次のようなものを正しいものとして拾ってしまう危険を挙げています。
このへん、すごくあるあるです。
個人的には、AIの失敗って「頭が悪い」というより、**“情報の棚卸しが下手”** なんだと思います。だから、棚を整理して渡すほうが効くわけです。
元記事が強調しているのは、narrow context という考え方です。
これは「狭い文脈」と訳せますが、要するに
という設計です。
ここで面白いのは、コンテキストは広ければ広いほど良い、という直感を否定している点です。
大きなAIほどたくさん入れたくなりますが、実務では「余計な情報で混乱する」ほうが痛い。これは人間の仕事でも同じですが、AIではさらに露骨に出る気がします。
この記事の核の1つがここです。
source of truth は「正本」「最終的に信頼する情報源」のことです。
たとえばコードベースなら、
が、古いドキュメントより優先されることが多いです。
一方で、製品の説明なら、
のほうが、昔の企画書より信頼できます。
つまり、情報には優先順位があるんですね。
これ、当たり前のようでいて、AIに渡すときはすごく大事です。AIは「置いてあるものを全部同じ重みで見てしまう」ことがあるので、こちらが
を明示しないと危ないわけです。
元記事の言い方を借りるなら、**“available materials are equally reliable” だとAIが誤解する**。
これはかなり本質的で、しかも地味に怖いポイントです。
元記事では、context package は難しいものではなく、かなり実用的に作れると言っています。入れるべきものの例はこんな感じです。
ADR は Architecture Decision Record の略で、設計判断を記録した文書です。
runbook は、トラブル対応や運用手順を書いたメモですね。
要するに、AIに「考えさせる」前に、迷わない材料をセットで渡す ということです。
これって、かなり人間っぽい仕事のさせ方なんですよね。新人に雑に「全部読んでおいて」ではなく、「まずこの資料だけ見て、このルールに従ってね」と渡すのに近いです。
ここも重要です。
元記事は、一般的な agent tools が強くても、そのプロジェクトの“真実の階層”までは最初から知らないと言っています。
例えば記事内では、具体例として次のようなプロジェクトを挙げています。
要するに、「このプロジェクトでは何が重要か」は、一般論では決まらないということです。
これは完全にその通りだと思います。現場のルールって、リポジトリの外にあることが多いんですよね。
READMEに全部は書いてないし、書けない。だからこそ、AI用に文脈を加工して渡す必要があるわけです。
記事の後半で面白いのが、overgeneralization への警戒です。
これは「1つの例を見て、そこから勝手に普遍ルールを作ってしまうこと」です。
AIはこれをやりやすいです。
たとえば、
みたいなことです。
これを防ぐために、元記事では材料にラベルを付けることを提案しています。
この分類、かなりいいです。
個人的には、AIに渡す情報って「内容」だけじゃなくて「身分証明」が必要なんだな、と思いました。
これは事実？ それとも例外？ それともこのプロジェクトだけの都合？
そのラベルがないと、AIは平気な顔で全部を“法則”にしてしまう。
この文章で一番面白いのは、AIを魔法みたいに賢くする話ではないことです。
むしろ逆で、
AIを賢くするのではなく、AIが働く“土台”を正しくする
という発想です。
ここ、すごく実務的です。
AIに期待しすぎると「もっと大きいモデルを使えば何とかなる」と考えがちですが、この記事はそうじゃない。
良い結果は、良い文脈設計から生まれる と言っているんですね。
これはたぶん、今後のAI開発や社内導入でもかなり効く考え方だと思います。
「AIに何を渡すか」を設計できるチームは、かなり強いはずです。
この記事の主張を一言でまとめると、こうです。
AIにはリポジトリ全部を見せるより、そのタスクに必要な“正しい文脈”だけを渡したほうがよい。
そのためには、
ことが大事です。
個人的には、これは「AI活用のコツ」というより、AI時代の情報整理術 だと思います。
AIが賢くなるほど、人間側の“文脈設計”の上手さが効いてくる。そこがなんだか面白いし、ちょっと責任も重いですね。
参考: Give AI the Context It Should See, Not the Whole Repository
