STUDIO TORIUMI / OBSERVATORY
Claude Code をはじめとするコーディングエージェントの実践知を、 Zenn・Qiita・Hacker News・Reddit から毎日集めて並べます。 公式ドキュメントに書いていない、実際に使った人の設定・運用・失敗談だけを拾うようにフィルタしてあります。
新着記事は流れていきますが、繰り返し語られている原則はそれほど多くありません。 日々の記事を読む前に、この6つを踏まえておくと吸収が速くなります。
エージェントの性能を決めるのは、モデルよりも「何を読ませたか」です。 関係ないファイルを大量に読ませると、肝心の情報が薄まって指示を取りこぼします。
作業の単位を小さく切り、区切りで文脈をリセットする。 長い調査は本体ではなくサブエージェントに投げて、結論だけ返させる。 この2つが効きます。
毎回チャットで「テストも書いて」「日本語でコメントして」と言うのは、
指示ではなく再発明です。CLAUDE.md のようなプロジェクト規約ファイルに書けば、
以後は黙っていても効きます。
コツは、書きすぎないこと。数百行の規約は読み飛ばされます。 「守らなかったら困ること」だけを20〜30行で書くのが実用的です。
テスト・型チェック・リンタ・ビルドコマンド—— エージェントが自分で正解を確かめられる手段があるかどうかで、成果物の質が変わります。 検証手段がない領域では、エージェントは「それらしいもの」を書いて終わります。
逆に言えば、テストが整っているコードベースほどエージェントは強くなります。 AI導入の投資先は、実はテスト整備です。
速度に慣れると、動いたコードをそのまま通したくなります。 しかし現場から繰り返し上がってくる失敗談は、ほぼすべて 「読まずにマージした差分」から出ています。
読む時間が惜しいなら、変更量のほうを小さくする。 レビューできない大きさの変更を作らせないことが、結果的にいちばん速くなります。
全自動で走らせたい気持ちはわかりますが、
取り返しのつくもの（ファイル編集、テスト実行）と、つかないもの
（push、デプロイ、削除、外部への送信）は分けて考えるべきです。
後者は自動承認から外す。事故が起きてからでは戻せません。
同じ間違いを繰り返すとき、その場で言い直すのは対症療法です。 規約ファイル・スクリプト・型・テストのどれかを直せば、次から間違えようがなくなります。
「うまく指示する技術」より、「間違えられない環境を作る技術」のほうが、長い目で見て効きます。
各記事の見出しと元リンクだけを掲載しています。本文は元サイトでお読みください。 並び順は、新しさ・反応の多さ・実践知らしさ（設定／運用／失敗談などの語）で決めています。
この条件に一致する記事はありません。
有用な情報の多くは英語で流れています。訳文を載せる代わりに、 引っかかりやすい語だけをここにまとめました。これだけ頭に入れておけば、 英語の記事もだいたい読めます。
元記事の本文は転載も翻訳もしません。見出しと元リンクだけを並べ、読むのは元サイトでお願いしています。 書いた人に読者が届くのが筋だと考えているからです。
掲載は推薦ではありません。機械的な収集なので、内容の正しさは保証しません。 冒頭の「定石」と、この用語集は、こちらで書いた文章です。