コーディングエージェントを毎日使っていると、モデルそのものより「周りの道具」で体験が大きく変わることに気づきます。指示ファイルの書き方、MCP との付き合い方、作業ツリーの分け方、UI の仕上げ方。ここ最近ブックマークして読み返しているものを 8 本、自分用のメモとしてまとめました。各リンク先は個人サイト redreamality.com のノートで、元ネタ（GitHub リポジトリや記事）への要約と出典がまとまっています。
なお、どれも私が作ったツールではありません。紹介しているのは第三者のプロジェクトや記事で、ここに書いた感想は私個人のものです。
1. CLAUDE.md は短く、汎用的に
最初に読み返したいのが 良い CLAUDE.md の書き方についてのノート です。LLM はセッションをまたいでコードベースを覚えないので、CLAUDE.md（や AGENTS.md）は毎回読まれる「入門書」になる、という前提から話が始まります。書くべきは技術スタックと構成（WHAT）、目的（WHY）、ビルドやテストの方法（HOW）の 3 点。逆に、特定タスクにしか効かない指示を詰め込むほどモデルに「関係ない」と判断されて無視されやすくなる、という指摘が刺さりました。詳細は別ファイルに逃がして必要なときに読ませる、コードスタイルは linter に任せる、/init の自動生成に頼らず一行ずつ手で書く。どれも地味ですが効きます。
2. MCP のスキーマを毎ターン送らない
MCP サーバーを増やすと、ツール定義だけでコンテキストが埋まっていきます。そこで面白いのが mcp2cli のまとめ。MCP サーバーや OpenAPI、GraphQL のエンドポイントを実行時に CLI に変換してしまうツールで、コード生成は不要です。OAuth のトークン取得と更新、env: / file: プレフィックスによる秘密情報の受け渡し、接続設定を名前付きで保存する bake モード、LLM 向けの --json / --toon 出力などがそろっています。エージェントには「必要になったら CLI を叩け」とだけ教えればよい、という発想の転換が気に入っています。
3. MCP を中心に据えたエージェントフレームワーク
反対に、MCP を土台にエージェントを組みたい人には lastmile-ai/mcp-agent のメモ が参考になります。Anthropic の「Building Effective Agents」で紹介されたパターン（router、orchestrator-workers、evaluator-optimizer など）を部品として組み合わせられる Python フレームワークで、Temporal をバックエンドにすれば一時停止・再開・リトライのある永続ワークフローにも伸ばせます。作ったアプリ自体を MCP サーバーとして公開できる点も実用的です。
4. オープンソースのコーディングエージェント OpenCode
ターミナルで動く OSS のエージェントとしては sst/opencode の概要ノート をどうぞ。インストール経路の多さ（npm、Homebrew、scoop、pacman など）に加えて、組み込みエージェントの分け方が分かりやすいです。フル権限の build、ファイル編集を拒否して bash 実行前に許可を求める読み取り専用の plan、複雑な検索を任せる @general サブエージェント。権限の段階をエージェント単位で切るのは、他のツールでも真似したい設計です。
5. 各社のシステムプロンプトを読み比べる
「よくできたエージェントは裏で何を指示されているのか」が気になるなら、AI ツールのシステムプロンプト収集リポジトリの紹介 が入口になります。Cursor、Devin、Replit、Windsurf、v0 などのプロンプトやツール定義をベンダー別に整理した公開リポジトリで、スター数は十万を超えています。もちろん非公式に集められた資料なので鵜呑みは禁物ですが、自分の CLAUDE.md やツール説明文を書くときの比較材料としては十分役立ちます。
6. AI っぽい UI をなくすデザインスキル
エージェントに画面を作らせると、どこかで見たようなグラデーションとカードの山になりがちです。Impeccable というデザインスキル集のノート では、typeset、layout、polish、audit といったコマンドと、61 項目の検出ルールで「AI 生成っぽさ」を取り除くアプローチが紹介されています。PRODUCT.md と DESIGN.md にプロダクトの前提と見た目のルールを書いておき、後から来るエージェントにも読ませる、という運用が地に足がついていて好印象でした。
7. git worktree は「並行作業の枠」として使う
人間側のワークフローでいちばん参考になったのが matklad 氏の git worktree 運用メモ です。worktree をブランチの代わりにするのではなく、main（読み取り専用の比較用）、work、review、fuzz、scratch の 5 つを固定で持ち、それぞれを「同時に走っている活動」に割り当てる。エージェントにレビューやテストを並走させるときにも、そのまま使える整理の仕方だと思います。
8. 月 2,500 PR という極端な事例
最後は少し毛色の違う話題として、月に 2,500 本の PR を本番に出したという X の投稿の要約。投稿者は、弱い型システムや lint ルールでできることには限界があり、コードベースが自分自身を形式的に検証できればレビューの問題は解消して、とても速く出荷できる、と主張しています。そのうえで Bend に強く期待しているそうです。そのまま真似できる話ではありませんが、「検証をどこまで機械に寄せられるか」が速度の上限を決める、という見方は覚えておく価値があります。
まとめると、エージェントの生産性はモデル選びよりも、指示を短く保つこと、ツール定義でコンテキストを汚さないこと、作業の場を分けること、検証を機械に任せることで決まる部分が大きい、というのが最近の実感です。気になったものがあれば、リンク先のノートから元のリポジトリや記事にたどってみてください。