聞いて、試して、失敗して、直す — チームのAI開発底上げで得た3つの教訓
聞いて、試して、失敗して、直す — チームのAI開発底上げで得た3つの教訓
チーム全員のAI開発スキルを底上げするため、毎日30分のペアプロ会を導入しました。スキルマーケットプレイスの配布実践、Databricksによる使用状況の可視化、そして自作ループコマンドの失敗と作り直し——この記事では、実際に手を動かして分かったことをそのまま共有します。
なぜ、始めることにしたのか
プロジェクトの都合でAIツールの利用そのものが制限されていた案件があり、チーム内でAI開発の経験差が大きく開いていました。触れられるメンバーとそうでないメンバーの差は日を追うごとに広がる一方で、個人任せにしていてもこの差は縮まらないと判断しました。
「聞いて終わり」では、経験の浅いメンバーに定着しません。毎日11時から30分、画面共有で1人がドライバーになりながら実際に手を動かす——そのサイクルを習慣にすることにしました。
目指す到達点：プロンプト → ハーネス → ループ
AI活用のレベルを3段階で整理しています。
| 段階 | 名称 | 内容 |
|---|---|---|
| STEP 1 | プロンプトエンジニアリング | AIとの対話をうまく設計する。Copilot ChatからCopilot CLI・Claude Codeへ |
| STEP 2 | ハーネスエンジニアリング | 型を強制する仕組みをつくる。スキルの使い方・作り方、APM・WAZAのキャッチアップ |
| STEP 3 | ループエンジニアリング | 自己完結的に改善を繰り返す。AIがスタートからゴールまで自律的に動く流れ |
ループエンジニアリングを目指す理由は、AIが自律的に動く流れを浸透させることで、人間は売上をつくる仕事に集中できるチームにしていくためです。
現在のペアプロ会では、実際に試したものとして Copilot CLI、Omnigent、並列サブエージェント実行、Draw.io生成スキル、APM、自作ループコマンド（guts-loop）を扱ってきました。
試した話 #1：スキルマーケットプレイスの仕組みを手で動かす
複数チーム・複数リポジトリでスキルがバラバラに乱立し、陳腐化していく課題への対策として、スキルを中央集権的に配布する仕組みを理解することにしました。
マーケットプレイスリポジトリ（marketplace.json）から apm marketplace add → apm install で各プロジェクトに配布する流れを、ペアプロ会で全員が実際に手を動かして体験しました。
得られたもの： 理解 → 利用 → 作成 → 配布まで一気通貫で動かすと、聞いた知識が実務の型になります。後述のguts-loopのスキル配布にも、この仕組みをそのまま再利用できました。
試した話 #2：Databricksで使用状況を可視化する
一人ひとりのコスト管理と、全メンバーのプロンプト情報をDatabricksに集約・分析して働き方を改善することを目指しています。OmniAgent経由のモデル選択統合と、Databricksでの個人ごとのレート制限（¥20,000/user/月）の設定を共有しました。
現在の段階では、個人ごとのレート制限は設定済みですが、実際に想定どおり止まるかの検証はこれからです。全メンバーのプロンプト情報を集約・分析する仕組みも、まだ構築中です。
得られたもの： インフラの完成を待つ必要はありません。先に進め方・手順をチームに浸透させておけば、基盤ができた瞬間から全員で走り出せます。
試した話 #3：自作ループコマンド「guts-loop」をつくった
ループエンジニアリングの実践として、AIに指示・実行・確認を自己完結で繰り返させる仕組みをプロジェクト用に作りました。
- プラン・作業状態・教訓（lessons）をファイルで管理し、worktreeで並行実行
- プランの規模に応じてモデルを自動で使い分け（コスト配慮）
/guts-loopで呼び出し →mode-a: task-queue（タスクを積んで順に消化）またはmode-b: goal-chase（ゴールを満たすまで自走）
ペアプロ会で全員がスラッシュコマンドから実際に呼び出して体験し、「みんなでガンガン回して、guts-loop自体を学習させてどんどん最適化していく」方針で日々の作業での運用を始めました。
失敗した話：ガードレールが、静かに素通りしていた
guts-loopには「PR作成前に確認を挟む（ガードレール）」という設計がありました。ところが、ペアプロ会のデモ中に予期しない挙動が起きました。
期待していた流れ：
プロンプト → /guts-loop 呼び出し → PR作成前に確認（ガードレール） → コミット/PR実際に起きた流れ：
プロンプト → スキル未呼び出しのままautopilotが実行 → 確認ステップ自体が存在しない → 不要なコミット+PRが自動作成ドライバーが guts-loop を呼び出さずに Copilot の autopilot にそのまま依頼した結果、確認ステップを持たないまま commit からPR作成まで静かに進みきっていました。被害は「不要なPRが1本」で済みましたが、誰も止めていないのに完了していたという点が問題です。
根本原因： ガードレールはスキルの中に定義されていました。呼ばれなければ、無いのと同じです。さらに調査すると、guts-loopの設計前提であるhookの仕様がClaude CodeとCopilot CLIで異なっていました。
| Claude Code | Copilot CLI | |
|---|---|---|
| hookでの文脈注入 | 各タイミングのhookでadditionalContextを注入できる | SessionStartのみ |
| 応答内容の取得 | hookから扱えるので完了時にも介入できる | Stop・SubagentStopに本文フィールドが無く取得不可 |
| ガードレール強制 | 成立する | スキル呼び出しを強制する場所がそもそも無い |
「hookで強制する」という設計は、Claude Code専用の前提でした。
直した話：hookで縛るのをやめた
guts-loopを捨て、loop-engineとして作り直しました。
Before（guts-loop）： hookで強制する設計。Claude Codeの仕様に依存しており、呼び出し忘れると確認ごと素通り。
After（loop-engine）： AI自身が説明文から選ぶ設計。
- hookは決定論的な仕事（状態の運搬・ログ）だけに徹する
- どのスキルを使うかは、各
SKILL.mdの description からAI自身が判断（迷えば loop-driver で明示呼び出し）
3層の責務を分離しました：
| 層 | パス | 役割 |
|---|---|---|
| レール層 | .claude/hooks/ | session_start・capture_prompt・subagent_stop・summarize が決定論的に発火。状態の運搬とログのみ |
| 判断層 | .claude/skills/ | loop-driver が生成⇄修正の自己完結を担う。context-recall で再開時の状況再構築、summarizer で成果集約 |
| 状態層 | .claude/state/ | セッションごとに分離された揮発データ（git追跡外）。全入力のログと作業状態 working.md |
この設計変更はmainにマージ済みで、ペアプロ会でチームにも共有しています。
まとめ：3つの持ち帰り
| # | 教訓 |
|---|---|
| ① | スキルは、配布まで手を動かして初めてチームの型になる |
| ② | インフラの完成を待たず、人の認識合わせから始める |
| ③ | ガードレールを「呼ばれたら効く」仕組みにしない——失敗は明文化して、資産にする |
3つの層の現在地は以下の通りです：スキルマーケットプレイスの実践は進んだものの定着はこれから、Databricksはインフラ構築中で本格運用は次のステップ、ループはguts-loopを作って壊して loop-engine として作り直しました。
聞いた話を実際に手を動かして試す場を、日常につくってみてください。詰まった話こそ、共有する価値があります。
お気軽にKDDIアイレットへお問い合わせください！