30秒サマリー

コーディングエージェントへ同じ注意を繰り返すなら、リポジトリの指示ファイルに残す価値があります。ただし、波括弧や関数名の長さまで自然言語の指示に任せる必要はありません。今日は、設計意図はAGENTS.md、機械判定できる規則はlintやテストへ分ける境界を考えます。

急浮上トピック3選

1. 指示ファイルの「実行可能化」

一言でいうと: エージェントへ守ってほしい規則のうち、機械的に判定できるものをlint、テスト、フックへ移し、違反時に必ず失敗させる考え方です。

なぜ今注目されているか: Fabien Sanglard氏が8月21日に個人のagent.mdを公開し、8月23日にHacker News上位へ浮上しました。8月24日12時ごろ（日本時間）の公開ページでは189ポイント、85コメントでした。議論では、波括弧や命名規則は文章ではなくlintで強制すべきだという意見が最上位にあり、指示と機械的制約の分担が焦点になりました。

知っておくべき度: ★★★★☆ — コーディングエージェントを使う人にとって、指示の追加だけで品質問題へ対処し続けると、文脈が長くなり、守られたかの判定も曖昧になります。

開発への接続: AGENTS.mdの各行へ「人の判断が必要」「既存ツールで検査可能」「小さなスクリプトで検査可能」の印を付けます。後ろ二つから一つだけCIへ移せば、エージェントと人間の変更に同じ基準を適用できます。

今日の一本

指示は設計判断を残す場所にする

My agent.md to improve LLM-assisted code qualityでSanglard氏は、コードレビューで同じ指摘を繰り返した経験から、短い関数名、層をまたがない設計、無関係な箇所を変更しないこと、バグ修正前に失敗するテストを書くことなどを指示ファイルへまとめました。本人の評価は「魔法の弾丸」ではなく、コードを読む作業は残る一方、レビューの焦点を書式から設計へ移しやすくなった、というものです。

ここからは編集部の整理です。指示ファイルに向くのは、なぜその層を越えてはいけないか、公開範囲を変える前に誰へ確認するか、変更範囲をどう考えるか、といった文脈依存の判断です。常に波括弧を使う、特定の形式でコミットを書く、既知の禁止パターンを含めない、といった判定可能な規則は、lintやテストへ移した方が違反を観測できます。

Hacker Newsの議論は、元記事のルールをそのまま採用することへの反論も含みます。コメントの量や関数名の長さはプロジェクトごとに意見が分かれ、固定値が別の読みにくさを生む可能性も指摘されました。持ち帰るべきなのは他人のagent.mdではなく、自分のレビュー履歴から頻出する問題を拾い、説明が必要な規則と実行できる検査へ分ける手順です。

コミュニティで見つけた一語

コンテキスト希釈（context dilution）

元記事では、会話や指示が長くなると、モデルが文脈の中ほどにある指示へ注意を向けにくくなる現象を「コンテキスト希釈」または「注意の希釈」と呼んでいます。筆者の対策は、機能ごとに新しいセッションを始め、品質が落ちたら指示ファイルを読み直させることです。

これは、すべての長い会話で同じ失敗が必ず起きるという保証された法則ではありません。ただ、機械検査できる規則を文脈から外せば、守るべき文章を短くし、違反を決定的に検出できます。

今日の5分アクション

AGENTS.mdや類似の指示ファイルを一つ開き、機械判定できる規則を一つだけ選びます。既存のlintやテストですでに検査しているかまで確認できれば完了です。

コピペ用プロンプト

あなたはコーディングエージェント向け規則の整理役です。
[対象リポジトリ] のAGENTS.md、CLAUDE.md、CONTRIBUTING.mdのうち存在するものを1つだけ読み、機械的に合否を判定できる規則を最大3件抽出してください。該当ファイルがなければ、その事実を1行で示して終了してください。

手順:
1. 抽出した規則ごとに、既存のlint、テスト、Gitフックで検査済みかを設定ファイルから確認する
2. 未検査の規則から、5分以内に検査方法を設計できるものを1件選ぶ
3. 実装はせず、使う既存ツールまたは最小スクリプトの入力と失敗条件を書く

制約:
- ファイルは変更しない
- 外部サービスへアクセスしない
- 主観的な設計判断を無理に数値化しない
- 所要時間は5分以内

出力:
1. 読んだファイル
2. 規則と現在の検査状況
3. 機械検査へ移す候補1件
4. 失敗条件と次の一手

参照元

中心となる原資料を確認する ↗