/note/tech

AIコーディングの原則

要約:

■ 1. AIコーディングツールとAI Slopの問題

  • AIコーディングツールは急速に進歩し利便性が高い
  • OSS界隈ではAI Slop(AIが生成する低品質なコードやテキスト)が問題となっている
  • チームではSlopが人数分だけ増幅され レビューとリワークがチーム全体に波及する
  • AIコーディングのメリットを上回る生産性の低下を招く

■ 2. コードの責任と所有権

  • LLMがコードを生成しても コミットに名前が刻まれるのは人間である
  • 深夜の障害対応で呼び出されるのも人間であり「AIが書いたから」は通用しない
  • AIは7〜8割のコードを書けるがプロダクション品質に仕上げるのは人間の仕事である

■ 3. コンテキストの共有とドキュメントの役割変化

  • 良いコードには設計の選択理由や棄却した選択肢のコンテキスト共有が必要である
  • 従来のコンテキスト共有:
    • 隣のシニアエンジニアとの会話やコードレビューで行われていた
    • ドキュメントは書かれても読まれないことが多くコンテキストの本体は人の頭の中にあった
  • AIへのコンテキスト提供の要件:
    • AIには雑談ができないためコンテキストを言語化して書くことが必須である
    • AIが必要とするのはコードそのものには書けない設計の選択理由・制約・前提である
    • コンテキストウィンドウの制限があるためドキュメントは適切なサイズに整理する必要がある
    • 長すぎるドキュメントが読みづらいのは人間も同じであり簡潔さの要件は両者に共通する
  • AIの登場によってドキュメントはオーバーヘッドではなく開発のスループットを決める重要な要素となった

■ 4. チームで守るべき原則

  • 判断は人間がする:
    • AIの提案をそのままコミットしない
    • オンコールで呼ばれたとき1000行の変更を説明できる状態を保つ
    • コードの品質は時に低くセキュリティ境界(認証・認可・入力検証)はAIが見落としやすい
  • 人間が読めるドキュメントを優先して書く:
    • 設計意図・制約・決定理由を人間の言葉で記す
    • ドキュメントは人とAIが共有するコンテキストである
    • AIだけが読む専用ファイル(CLAUDE.mdなど)はあくまで補助であり本体ではない
    • 人間向けのドキュメントを充実させればAIへの指示は自然と最小化される
  • AIへの指示は「発見できないことだけ」書く:
    • コードを読めばわかることを繰り返す必要はない
    • AIが繰り返し失敗したこと・プロジェクト固有の制約・ツール選択の理由など「コードベースの外にある知識」だけを補助的に書く

■ 5. まとめ

  • コードの責任を取るのは人間である
  • 判断は自分で下しコンテキストを言語化し人間が読めるドキュメントに投資する
  • AI専用の指示はいずれ陳腐化するが人間のために書いたドキュメントの価値は残る

■ 6. 参照・エビデンス

  • 責任の原則:
    • Simon Willison(2025-12-18): コンピュータはアカウンタビリティを持てないためhuman in the loopとしての判断が人間の仕事である
    • Matteo Collina(Node.js TSC Chair・Fastify作者 2026-01-18): コードを出荷するとき名前がついており AIで速く動けても自分の判断を外注することはできない
    • Birgitta Böckeler(Thoughtworks Distinguished Engineer 2025-07-09): 深夜にオンコールで呼ばれるのは人間であり LLMはコンパイラではなく推論器であり使用は常にリスクアセスメントである
  • AGENTS.md・コンテキストファイルの実証研究:
    • Gloaguen et al.(ETH Zurich 2026-02-12): 138リポジトリ・5694件のPRを対象とした実証研究。LLM生成のコンテキストファイルはエージェント性能を2〜3%低下させ 開発者が書いても4%改善に留まる一方コストは20%以上増加。不要な要件がタスクを困難にするため人間が書くファイルは最小限の要件のみ記述すべきと結論づけた
    • Vercel Engineering(2026-01): 発見できない知識だけを書いた圧縮インデックスが100%のpass rateを達成
    • Upsun Developer Center(2026-02): CLAUDE.mdは.gitignoreのように扱い エッジケースを発見するたびに育て不要になれば刈り込む
  • コミュニティの議論:
    • Hacker News(Evaluating AGENTS.md 2026 76ポイント・36コメント): 論文著者のnielstron本人がスレッドに参加。モデルがセッション開始時にREADMEとCONTRIBUTING.mdを自動でインジェストすべきという提案に著者が賛同。ユーザーpamelafoxがエージェントが失敗したときだけAGENTS.mdに追加し変更を戻して再実行して改善を確認するという実践的な運用法を共有した
    • Hacker News(Compressed Agents.md 2026 72ポイント・34コメント): SkillsよりAGENTS.mdが有効な理由はエージェントが取得するかどうかを判断する必要のない確実な文脈提供にあるという議論が展開された
  • ドキュメント・仕様駆動開発:
    • GitHub Blog(2025-11): 2500以上のリポジトリ分析。成功するコンテキストファイルの共通点は「具体的なコマンド・明確な境界・コードで示すスタイル例」である
    • Addy Osmani(Google Chrome 2026-01): 仕様はwhatとwhyに集中すべきであり 巨大な仕様を一度に渡してもコンテキストウィンドウとattention budgetが邪魔をする
    • Thoughtworks(2025-12): 仕様はGateではなくエージェントがリアルタイムで消費し行動するための会話であり 従来のデザインドキュメントと異なり仕様が実際に使われるようになった点が決定的な違いである