デジタルエンジニアリング部の松本です。
2026年4月22日（水）、ふくおかフィナンシャルグループ（FFG）様が主催する「FFGのMaNaBi-Ba第6回〜我が最強のSKILL.mdを見よ〜」にLT枠として登壇してきました。 テーマは、普段の業務で使い込んでいるClaude Codeを、どうやって自分とチームに馴染ませていくかです。
本記事では、その登壇内容をテックブログ向けに再構成してお届けします。 想定する読者は以下のとおりです。
Claude Code特有の仕組みに関する話題もありますが、「AIエージェントを育てる」という発想自体は、他のエージェント型ツールにも応用がきく内容にまとめたつもりです。
FFGのMaNaBi-Ba第6回〜我が最強のSKILL.mdを見よ〜 は、Claude CodeやCursorなどのAIエージェントツールを実際に使っている方々が集うコミュニティイベントです。自分のSKILL.md（AIエージェントに与える指示書）を持ち寄って、知見を共有することを目的にしています。
イベントページ：【増枠】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個ほどになり、登壇スライドではそれらをタイル状に敷き詰めて見せました。
10分のLTで全部は話しきれないため、ルール1つ・スキル1つの計2つに絞って紹介することにしました。
three-role-workflow（ルール）wrap-up（スキル）なぜこの2つかというと、筆者が実際にハマった2つの大きな落とし穴を、それぞれが塞いでくれたからです。 本記事では、その落とし穴と対策を順に解説していきます。
結論を先に置いておくと、お伝えしたい縦串のメッセージは1つです。
Claude Codeは「使うツール」ではなく、「育てる相棒」である。
以降、この結論に至るまでの道のりを、失敗談とセットで振り返ります。
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の型エラーでビルドすら通らない、という状況でした。
AIは確かに優秀です。そのうえで、このとき筆者が得た学びは1つでした。
AIを1人にしてはいけない。
暴走を抑えるために、2つの仕組みを組み合わせて運用しています。
順に説明します。
three-role-workflowというルールで、ひとつのタスクを次の3つの役割に分けて進めます。
| 役割 | 担当 | 責務 |
|---|---|---|
| Planner | 計画する人 | 要件分析、実装計画の策定、リスクと制約の洗い出し |
| Executor | 実装する人 | 計画に沿って実装する。計画外のことはしない |
| Reviewer | レビューする人 | 計画と成果物を照合し、問題があれば差し戻す |
ここでのポイントは、同じエージェントが複数の役割を兼ねないことです。 計画した本人が実装すると、どうしても自分の計画を疑えません。計画・実装・レビューを別のサブエージェントに割り当てることで、一種の内部監査のような構造が生まれます。
Executorが暴走しかけても、Reviewerが止めます。 Reviewerが通した成果物だけが承認済みとして扱われます。
ただし、この仕組みで気をつけたいのが無限ループです。 差し戻しが永遠に続いてしまうと、AIのトークンも筆者の時間も消費され続けてしまいます。 そこで、以下のルールを置いています。
経験則として、3回目で収束しない問題は、実装力の不足というより計画そのものの穴に起因するケースが多い印象です。 人間が一度立ち止まって計画を練り直すほうが、結果として速く進みます。
三者分離が「内部の分業」だとすれば、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と仕組みの相互チェック」を設計に組み込むことが、暴走を抑える近道でした。
2つ目の落とし穴は、AIの記憶に関するものです。
Claude Codeのセッションは、一度終わると、そのセッション内で蓄えた文脈がそのままでは次に引き継がれません。 次に起動したときには文脈がリセットされた状態から始まります。 筆者の好み・判断軸・過去にやらかした失敗といった情報は、一切持ち越されないわけです。
この「毎回リセット」が何を引き起こすかというと、次のような事象です。
能力そのものは高いのに、毎回「初めまして」から始まる。 これが2つ目の落とし穴でした。
この問題に対して使っているのが、wrap-upというスキルと、memoryという永続化の仕組みの組み合わせです。
wrap-upは、セッション終了時にAI自身で振り返りを行うスキルです。 人間がメモを取るのではなく、AIがそのセッションの学びを抽出してファイル化するところがポイントです。
流れは以下の4ステップです。
wrap-upを実行するこのやり方の利点は、AIが自分で自分を学習させる構造になっていることです。 人間側がすべての知見を記録・整理する必要がなく、気づいたこと・決めたことが自動的にナレッジとして積み上がっていきます。
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へと育っていきます。 最初はあくまで一般的な優等生ですが、使えば使うほど、自分たちの文脈に馴染んでくる感覚があります。
対策②で伝えたいのは、以下です。
AIは使うものではなく、育てるものである。
wrap-upはその「育成」を駆動するスキル、memoryは育成結果を蓄える永続領域、と位置づけています。
本記事で扱った2つの落とし穴と対策を、改めて表で整理します。
| 弱点 | 対策 | 本質 |
|---|---|---|
| 1人だと暴走する | three-role-workflow＋hooks |
外から制約をかける |
| 記憶が消える | wrap-up＋memory |
自発的に育てる |
Before：一般的な優等生。誰にでも70点の答えを返す。筆者やチームの文脈を知らない。
After：筆者・チーム専用のAI。判断軸、好み、過去の失敗履歴を共有している。初動から「自分たちの言葉」で返してくれる。
冒頭で予告した縦串のメッセージを、ここで改めて置かせてください。
Claude Codeは「使うツール」ではなく、「育てる相棒」である。
制約を設けて暴走を止める。 学びを累積してパーソナライズする。 この2軸で運用することで、AIエージェントは徐々に自分やチームの「延長」として機能するようになっていきます。
当日の発表では、最後にふたつの問いを会場に投げかけました。 懇親会でも実際にいろいろな方から回答をいただき、大きな学びがありました。
- 皆さんが暴走を止めるために、どんな工夫をしているか
- 皆さんのAIは、どんな風に育っているか
読者の皆さんにも、ぜひ同じ問いを持ち帰っていただければ幸いです。 会社やチーム、プロジェクトごとに「育て方」は異なるはずで、他の方の知見を聞くたびに自分の運用を見直すきっかけになっています。
最後に、素晴らしい登壇機会をいただいたふくおかフィナンシャルグループの皆様、主催・運営の皆様、会場でたくさんの議論を交わしてくださった参加者の皆様に、この場を借りて御礼申し上げます。
本記事が、Claude Codeや他のAIエージェントを運用している方にとって、なにかひとつでもヒントになれば幸いです。