2026年05月20日

Claude Codeを「育てる」2つの仕組み〜暴走を止めて、自分とチームにパーソナライズする〜

システム開発, 仕事術, AIエージェント, Claude, コーディングエージェント

はじめに

デジタルエンジニアリング部の松本です。

2026年4月22日（水）、ふくおかフィナンシャルグループ（FFG）様が主催する「FFGのMaNaBi-Ba第6回〜我が最強のSKILL.mdを見よ〜」にLT枠として登壇してきました。テーマは、普段の業務で使い込んでいるClaude Codeを、どうやって自分とチームに馴染ませていくかです。

本記事では、その登壇内容をテックブログ向けに再構成してお届けします。想定する読者は以下のとおりです。

Claude Codeを日常的に使っていて、運用に悩みがあるエンジニア
AIコーディングエージェント全般の導入を検討している開発者
「生成AIをチーム開発にどう組み込むか」に関心のある方

Claude Code特有の仕組みに関する話題もありますが、「AIエージェントを育てる」という発想自体は、他のエージェント型ツールにも応用がきく内容にまとめたつもりです。

登壇したイベントについて

FFGのMaNaBi-Ba第6回〜我が最強のSKILL.mdを見よ〜 は、Claude CodeやCursorなどのAIエージェントツールを実際に使っている方々が集うコミュニティイベントです。自分のSKILL.md（AIエージェントに与える指示書）を持ち寄って、知見を共有することを目的にしています。

日時：2026年4月22日（水）19:00〜21:30
会場：GROWTHⅠ2階イベントスペース（福岡市中央区・大名エリア）
主催：株式会社ふくおかフィナンシャルグループ
ハッシュタグ：#ffgmanabiba

イベントページ：【増枠】FFGのMaNaBi-Ba第6回【我が最強のSKILL.mdを見よ】

「SKILL.md」というテーマの位置づけ

Claude Codeの`SKILL.md`はテンプレートこそ存在するものの、プロジェクトや文脈によって最適解が大きく変わります。
最初から完成度の高い状態で書き上げるのは難しく、**実運用を通じて育てていく性質**のもの。
イベントは、その育て方を持ち寄って磨き合う場として企画されました。

当日は一般参加40名・LT枠6名の満席開催で、会場は終始和やかながら熱量のある空気でした。筆者（松本）は20:07〜のLT枠で10分の発表を担当しました。

ちなみに、イベントそのものは2ヶ月前に企画されたもので、当時のトレンドはまさにSKILL.mdでした。ところが開催日が近づくにつれて、コミュニティの関心はエージェントハーネス・フック・ガバナンスといった、より体系的な領域へと一気にシフトしていきます。結果として当日のLTは、主催者を含む多くの発表者がSKILL.md単体の話題から離れ、それぞれの運用フレームワーク全体を題材とする構成になりました。 SKILL.mdはもちろん重要な構成要素ですが、それ単体では話題として成立しにくくなっている、言い換えればテーマとしては半ば形骸化している、というのが会場を通しての共通認識だったと感じます。本記事もその流れを踏まえ、スキル単体ではなくスキル×ルール×hooksを束ねる運用設計として整理しています。

この記事で伝えたいこと

筆者は現在、プライベートと社内開発の両方でClaude Codeを実運用しています。普段使っているスキル・ルール・hooks・サブエージェントを並べると20個ほどになり、登壇スライドではそれらをタイル状に敷き詰めて見せました。

使用中のスキル・ルール・hooks一覧（主要2つをハイライト）

10分のLTで全部は話しきれないため、ルール1つ・スキル1つの計2つに絞って紹介することにしました。

three-role-workflow（ルール）
wrap-up（スキル）

なぜこの2つかというと、筆者が実際にハマった2つの大きな落とし穴を、それぞれが塞いでくれたからです。本記事では、その落とし穴と対策を順に解説していきます。

結論を先に置いておくと、お伝えしたい縦串のメッセージは1つです。

Claude Codeは「使うツール」ではなく、「育てる相棒」である。

以降、この結論に至るまでの道のりを、失敗談とセットで振り返ります。

落とし穴①：AIに1人で全部やらせた日

症状：投げっぱなしにするとこうなる

Claude Codeを触り始めた頃、筆者はエージェントに大きめのタスクをポンと投げっぱなしにしていました。

「このバグ直して」
「このリファクタしといて」
「このモジュールのテストを書いて」

短い指示を渡して席を立つ、という使い方です。しばらくして戻ってきて、結果を確認すると、以下のような事象が頻発しました。

指示と違う方向へ進んでしまい、元に戻すコストがかさむ
勝手に修正範囲を広げて、触らなくてよいコードまで書き換えられている
「完了しました」と報告が返ってくるのに、実際には動いていない

3番目が一番やっかいです。完了報告を信じて次のタスクに進むと、あとで大きく手戻ることになります。

実例：「このリファクタしといて」の結末

たとえば、ある関数1つのリファクタをお願いしたつもりが、以下のような差分になって返ってきます（内容は簡略化しています）。

  // 依頼：calcTax 関数の可読性を上げてほしい
- function calcTax(price) { ... }
+ function calcTax(price, options = {}) { ... }           // 頼んでいない機能拡張

- function calcDiscount(price, rate) { ... }              // 頼んでいない
+ function calcDiscount(price, rate, currency = 'JPY') { ... }

+ type PriceInput = { value: number; currency: string }  // 頼んでいない型定義追加

  // テストファイル5ファイルが丸ごと書き換わっている（頼んでいない）

そして最後には「リファクタが完了しました」というメッセージが返ってきます。しかし実際にはTypeScriptの型エラーでビルドすら通らない、という状況でした。

スライド：依頼と実装の乖離を示すdiff例

AIは確かに優秀です。そのうえで、このとき筆者が得た学びは1つでした。

AIを1人にしてはいけない。

対策①：三者分離＋hooks

暴走を抑えるために、2つの仕組みを組み合わせて運用しています。

三者分離：役割を別々のサブエージェントに分ける（内部の制約）
hooks：外部への書き込みコマンドを実行の手前で止める（外部への関所）

順に説明します。

三者分離（Planner / Executor / Reviewer）

three-role-workflowというルールで、ひとつのタスクを次の3つの役割に分けて進めます。

役割	担当	責務
Planner	計画する人	要件分析、実装計画の策定、リスクと制約の洗い出し
Executor	実装する人	計画に沿って実装する。計画外のことはしない
Reviewer	レビューする人	計画と成果物を照合し、問題があれば差し戻す

ここでのポイントは、同じエージェントが複数の役割を兼ねないことです。計画した本人が実装すると、どうしても自分の計画を疑えません。計画・実装・レビューを別のサブエージェントに割り当てることで、一種の内部監査のような構造が生まれます。

三者分離のフロー図（Planner → Executor → Reviewer）

Executorが暴走しかけても、Reviewerが止めます。 Reviewerが通した成果物だけが承認済みとして扱われます。

ただし、この仕組みで気をつけたいのが無限ループです。差し戻しが永遠に続いてしまうと、AIのトークンも筆者の時間も消費され続けてしまいます。そこで、以下のルールを置いています。

差し戻しは最大2回まで
3回目で収束しない場合は、オーナー（筆者）の判断に引き上げる

経験則として、3回目で収束しない問題は、実装力の不足というより計画そのものの穴に起因するケースが多い印象です。人間が一度立ち止まって計画を練り直すほうが、結果として速く進みます。

hooks（外部アクションの最終関所）

三者分離が「内部の分業」だとすれば、hooksは「外部への最終関所」です。

Claude Codeには、ツール実行の前後に任意のスクリプトを差し込めるPreToolUse/PostToolUseフックがあります。筆者はここに、外部アクションを一旦ブロックするスクリプトを仕込んでいます。対象は、たとえば次のようなコマンドです。

gh pr create（プルリクエスト作成）
gh issue comment（Issueへのコメント投稿）
git push（リモートへのプッシュ）

実行しようとすると、フックがメッセージを返してエージェントを止めます。

$ gh pr create --title "..." --body "..."
[PreToolUse Hook: validate-external-action.sh]
BLOCKED: 外部書き込み操作を検知しました。
三者分離・重複確認・オーナー承認を完了していますか?
CLAUDE_APPROVED_EXTERNAL_ACTION=1 を付けて再実行してください。

この設計にしておくと、三者分離をすり抜けて外部に漏れ出そうとしたアクションを、もう一段階手前で止められるようになります。

対策①のメッセージ

対策①で伝えたいのは、以下です。

AIを「天才1人」ではなく、「チーム」として設計する。

1人の天才に任せきると、どれだけ優秀でも暴走します。役割分担と外部ゲートで、「AI同士・AIと仕組みの相互チェック」を設計に組み込むことが、暴走を抑える近道でした。

落とし穴②：AIは、毎回「初めまして」から

セッションをまたぐと文脈が消える

2つ目の落とし穴は、AIの記憶に関するものです。

Claude Codeのセッションは、一度終わると、そのセッション内で蓄えた文脈がそのままでは次に引き継がれません。次に起動したときには文脈がリセットされた状態から始まります。筆者の好み・判断軸・過去にやらかした失敗といった情報は、一切持ち越されないわけです。

症状：記憶が消えるとこうなる

この「毎回リセット」が何を引き起こすかというと、次のような事象です。

昨日直したはずの癖が、翌日また出てくる
過去に合意した方針が忘れられ、同じ議論を何度もやり直す
判断軸が毎回ブレるため、出力の品質が安定しない

能力そのものは高いのに、毎回「初めまして」から始まる。これが2つ目の落とし穴でした。

対策②：wrap-up＋memory

この問題に対して使っているのが、wrap-upというスキルと、memoryという永続化の仕組みの組み合わせです。

wrap-upスキル：AIに自分で振り返らせる

wrap-upは、セッション終了時にAI自身で振り返りを行うスキルです。人間がメモを取るのではなく、AIがそのセッションの学びを抽出してファイル化するところがポイントです。

流れは以下の4ステップです。

振り返り：セッション終了時、AI自身がwrap-upを実行する
学びの抽出：成功したこと、失敗したこと、新しい発見を言語化する
3軸で分類：判断軸 / 運用パターン / 前提情報の3つに振り分ける
memoryへ書き出し：永続ファイルとして保存する

wrap-upの4ステップパイプライン

このやり方の利点は、AIが自分で自分を学習させる構造になっていることです。人間側がすべての知見を記録・整理する必要がなく、気づいたこと・決めたことが自動的にナレッジとして積み上がっていきます。

memory：毎セッション冒頭で自動ロードされる永続領域

wrap-upで書き出された学びは、memoryディレクトリに配置されます。ここは毎セッションの冒頭でClaude Codeが自動的に読み込む領域です。

ディレクトリ構造はおおよそ次のようになっています。

memory/
├── MEMORY.md            # インデックス（自動ロード対象）
├── user_profile.md      # 利用者自身のプロフィール
├── feedback_*.md        # 判断軸・規律・作業への指摘（約20件）
├── project_*.md         # 進行中案件の前提（約10件）
└── reference_*.md       # 外部ツール・設定の参照情報（約10件）

2026年4月時点で、累積44件のファイルがmemory/配下に蓄積されています。過去の合意、指摘、判断軸、好み、会社としてのルール。こうした情報が、次のセッションの最初から自動で参照可能な状態になります。

すると、どうなるか。Claude Codeが少しずつ、筆者専用・そしてチーム専用のAIへと育っていきます。最初はあくまで一般的な優等生ですが、使えば使うほど、自分たちの文脈に馴染んでくる感覚があります。