同じ Claude で差がつく 4D とループエンジニアリング

同じリポジトリで同じ Claude Code を使っていて、あるタスクに 3 日かかる人と 1 日で終わる人がいます。差を作っているのはプロンプトの上手さではありません。 任せ方・伝え方・見極め方・責任の持ち方という 4 つの型をどこまで深く持っているか、そしてその型を人の手で回すのをやめて仕組みに回させているかどうかです。

---

モデルが良くなっても、隣の席との差は縮まらない

2026 年 9 月 1 日に Claude Fable 5.1 が公開されました。キャッシュ読み取りの価格が下がり、一般的な用途では Fable 5 より約 25% 安く、エージェント的な使い方では最大およそ 45% 安くなっています（Anthropic の発表）。エージェント的なコーディングや長時間タスクのベンチマークも軒並み上がりました。

それでも、同じツールを配られたエンジニアの間の差は縮まりません。手元で観察している範囲では、速い人と遅い人の違いはだいたい次の 3 点に現れます。

モデルが賢くなるほど、この差は広がります。速い人は新しいモデルの伸びをそのまま自分の速度に変換できる一方、遅い人は毎回の対話にかかる人間の時間が変わらないためです。

4D という土台

Anthropic が提供している学習リソースの Claude Academy（AI Fluency）は、AI と働くための型を 4 つに整理しています。日本語で言い直すと、任せ方（Delegation）・伝え方（Description）・見極め方（Discernment）・責任の持ち方（Diligence）です。この 4 つを土台と見て、その上にループエンジニアリングを載せる、という捉え方をしています。

任せ方：半年前の判断を持ち越さない

「これは AI には無理」と一度決めた判断が、モデルが更新されても残り続けます。半年前のモデルを前提にした線引きが、いまのボトルネックになっているという状態です。

そこで、モデルが新しくなるたびに、自分がまだ手でやっている作業をひとつ選んで、もう一度まるごと任せてみます。できたら手放し、できなければ何が足りなかったかを記録します。逆に「絶対に自分がやる」も決めておきます。本番 DB の変更・認証設定・外部への送信は AI には提案までにとどめ、実行は人が行います。

調べる係と作る係を分けるのも同じ考え方です。調べる係には「原因の候補と根拠だけ返して」と頼み、その結論だけを作る係に渡します。同じセッションで両方やらせると、途中の探索ログが後半の判断を濁らせます。

伝え方：渡す量ではなく境界を決める

読めるコンテキストが 100 万トークンに増えても、長い文書の中の大事な 1 行を見落とす性質は変わりません。人間も分厚い資料を渡されると要点を外すのと同じです。入るようになったことは、入れるべきになったことを意味しません。

CLAUDE.md には、やってはいけないこと・テストの実行コマンド・フォルダ構成だけを書き、200 行以下に収まっているかを確認しています。設計思想の長文は別ファイルに切り出し、「必要なら読んで」とだけ書いておきます。オントロジーやグラフのような大きな構造物も、本文に貼るのではなく検索できるツールとして渡し、AI が必要な分だけ取りに行く形にします。この情報の絞り方そのものはコンテキストエンジニアリングの領域です。

依頼するときは、触っていい場所・触らない場所・終わりの条件の 3 行を必ず添えます。終わりの条件は npm test が通ることのように機械で判定できる形にします。 そうすると失敗したときに AI 側で気づいて直せます。

見極め方：「たまたま」を潰す

AI の出力は毎回少し違います。手元の 1 件でうまくいっても、それがたまたまだった可能性は残ります。「良くなった気がする」で採用すると、翌週に別のケースで壊れます。

そこで、自分がよく頼むタスクを 10〜30 件、期待する出力とセットでファイルに置いています（お手本テスト）。スキルや CLAUDE.md を直したら毎回これを回します。判定は最初は「テストが通るか」だけで足ります。同じケースを 3〜5 回走らせるのも忘れないようにしています。1 回通ったことと 5 回中 5 回通ったことは別物で、後者だけが仕組みとして使えます。

失敗したときは、最終出力ではなく途中経過のトランスクリプトを読み、どこで情報が足りずに推測したのかを 1 箇所見つけます。Claude 本人に「何があればもっと良くできたか」と聞くのも早いです。

そして見極めで失敗が出たとき、直す先はテストではありません。原因はたいてい伝え方が曖昧か、任せ方が間違っているかのどちらかで、渡すトークンを増やしても直りません。見極め方は、任せ方と伝え方に戻るための入口として置いています。

責任の持ち方：最後は人が持つ

「Claude が書いたので」がレビューの言い訳になると、チーム全体のコード品質が下がります。プルリクエストには何を確認したかを自分の言葉で書きます。テストが通ったこと、境界値を手で確認した件数、認証周りに差分がないこと、といった粒度です。

お金・認証・個人情報に触る変更は、任せ方の段階で「渡さないリスト」に入れたうえで、テストと人のレビューの両方を通します。Fable 5.1 では AI 生成物へのウォーターマークが EU AI Act 対応として入りました。どこが AI 生成なのかを説明する必要が出てくる場面はこれから増えるはずなので、追跡できる形を先に作っておくつもりです。

自然文で頼むか、スキルにするか

伝え方の一部として、指示を毎回書くのか、スキルとして固めるのかの判断があります。

目安は、同じ指示を 3 回目に書いたときです。そのとき手元にあるメモをそのまま SKILL.md の初版にします。

ループエンジニアリング：4D を仕組みに回させる

Claude Code の開発者である Boris Cherny 氏は 2026 年 6 月のインタビューで、自分はもう Claude にプロンプトを打っておらず、Claude にプロンプトを打って次に何をするか決めているのはループであり、自分の仕事はそのループを書くことだと語っています。その数日後に Google の Addy Osmani 氏が、この手法に Loop Engineering という名前と型を与えました。人間が 1 回ずつプロンプトを打つ代わりに、AI に指示を出し続ける仕組みそのものを設計する、という考え方です。

4D との関係で言うと、中級者と上級者の分かれ目がここにあります。

やり取りの回数がそのまま人間の時間になるのが中級者の状態です。ループ化すると、人はループの外側に立ち、ループを設計する側に変わります。

ループにする前に決めること

ループは条件を満たさないまま回すと、コードとトークンだけが増えます。回す前に次を決めています。

第 1 段階から始める

いきなり全自動にはしません。段を分けて上げていきます。

第 1 段階から始めて、お手本テストが安定したら 1 段上げます。

正直に書くと、ループは本物ですが、まだ多くの開発者には必要ありません。自動テストがないコードや、レビューが詰まっているチームでループを回すと、レビュー待ちのコードが増えるだけで逆効果になります。先にお手本テストと自動テストを整えるほうが早いです。

いま試していること

社内で取り組んでいるのはオントロジーの作成です。業務のドメイン知識と、隣り合うタスク同士の関係性を AI 側に持たせることで、業務を理解したうえでループを回せる状態を目指しています。リポジトリに置いて更新しながら、どこまでを AI に見せるかの線を引いている段階で、手応えと呼べるところまでは来ていません。個々の端末で常時ループを回すのか、中央で 1 本回して結果を共有するのかも決めきれていません。

まとめ

差がつく層は 3 つに分かれます。伝え方から見極め方までの内側の往復を速く回すことが今日の差を作り、任せ方と責任の持ち方を定期的に見直すことが半年後の差を作り、内側の往復を AI に渡してループを設計することがその先の差を作ります。

100 万トークンは伝え方の規律がないと害になり、ループは見極め方の検証器がないと暴走します。モデルの更新に振り回されないためには、4D の側を先に整えておくのが結局は速い、というのがいまの実感です。

持ち帰りとして手を動かすなら、CLAUDE.md を 3 項目に削ること、お手本テストを 10 件置くこと、第 1 段階のループを 1 本つくることから始められます。

KDDIアイレットでは、こうした型の整備と定着をAI 駆動開発の実プロジェクトを通じて支援しています。自社のチームで AI 駆動開発を回せる状態を目指すならAIDD インハウスが近いはずです。お気軽にご相談ください。