グロービスでは AI コーディングのメインツールを Claude Code (CLI 版) に統一する方向で運用しています。利用ログを取り始めて改善の打ち手を入れたところ、すぐに次のような成果が出ました。
- 毎月の開発時間を およそ 100時間 節約
- 開発セッションのリードタイムが 約 10% 短縮
本記事では、この成果につながった理由と、改善のきっかけとなったボトルネックをご紹介します。
こんなことありませんか？
- 別の作業から戻ってきたら、AI が 進めてよいですか？ のまま何分も止まっていた
- 明らかに問題のない内容を確認されて、お願い とだけ返すターンがやけに多い
- 寝る前に あとは任せる と言ったのに、朝起きたら 次に進めますか？ で停止していた
- コミットしますか？ → コミットして → push しますか？ → push して と、確認と承認のやり取りが延々と続く
- 同じ流れを何度も繰り返すうちに、自分が
/commit-pushを叩く役になっていた
こうしたことが続くと、AI に任せられるはずだった作業でも、結局は画面に張り付く必要が生じ、開発者の集中を妨げる要因になります。
どれもAIが悪いというより、エージェントとの役割分担がうまくいっていない、という状態です。
Anthropic をはじめ各社は AI エージェントの 長期駆動 (long-horizon agent) に舵を切っており、16体の Claude を並列に動かし、C コンパイラをゼロから実装する実験 のように、答えが機械判定できる領域では大きな成果も出ています。
ですが、プロダクト開発はそう単純にはいかず、現場では長期駆動以前の段階、たとえば不要な確認で止まる・ユーザーが先回りで確認を促す・master へ直接コミットしようとする、といった場面で躓くケースが多く見られます。
どんな改善ができたか
実際に入れた打ち手はいくつかありますが、ここではドメインや個別事情に依存しにくい3つの打ち手をご紹介します。
ユーザーが 進めて とだけ返す確認をなくした
直近のセッションログ1000件を Claude に分析させたところ、Claude が確認で締めて止まるパターンが頻発していました。たとえば次のようなものです。
- コミットしますか？、commit push しますか？、PR作成に進みますか？
- 適用しますか？、反映しますか？、修正しますか？、実装しますか？
- Notion を更新しますか？、次は X を見ていきましょうか？
約1000回の確認質問のうち、こうした「進めても構わない」ケースが 40% を占めていました。Hook で省略すれば、月およそ 100時間分の承認待ちが浮く試算です。
任せておけば数分で終わったのに、承認待ちで何倍も長くかかったケース
上の3例は、5分以上待たせて結局は承認だけだったケースを実ログから抜き出したものです (ユーザー発言は伏字)。
- 1例目: 任せておけば 2分21秒 で終わったのに、承認を待っていたために 18分弱 かかってしまった
- 2例目: 任せておけば 49秒 で終わったのに、承認を待っていたために 約 6分 かかってしまった
- 3例目: 任せておけば 17秒 で終わったのに、承認を待っていたために 5分半 かかってしまった
3例目がもっとも極端で、Claude 自身が修正方針を詳細にまとめた上で最後に 修正しますか？ と尋ねたケースです。Hook で確認をスキップさせていれば、17秒で完了していた処理に、ユーザーが戻ってくるまでの5分半がそのまま上乗せされてしまいました。
あるセッションでは、こうした単純な承認待ちが繰り返されて、1時間ほどが確認待ちに費やされていた 例もありました。
ユーザーが 本当？ と聞き直す必要をなくした
ログ中で次のような流れが繰り返し記録されていました。
- ユーザーが何かを質問する
- Claude が確信を持って説明する
- ユーザーが 本当？ と疑問を投げる
- Claude が再調査して、前言を撤回する
興味深いことに、本当？ と尋ねるだけでも、同じように Claude の精度が上がりました。新たな情報を渡していないものの、AI 側が自発的に再調査して、最初の説明の誤りに気付いて訂正するケースが多く見られました。
この傾向は、日々 AI を活用する中でも見られます。Claude を含む現行の AI モデルは、最初のシステムプロンプトで先回りして指示しておくよりも、応答が返ってきた直後にユーザー側が反応することで挙動を引き出すほうが、効果が出やすい傾向があります。Hook を使うことで仕組みとして組み込めるため、Claude Code はこの特性と相性のよい環境です。
約1ヶ月分から該当ケースを抽出すると 146件 にのぼりました。内訳は推測のまま終わらせてしまったことや、既存コードや API 挙動の誤認、存在しないファイルへの言及などです。一例としては、Claude が ActiveRecord はスキーマキャッシュに存在しないカラムへの代入を無視するため、エラーにはなりません と断言した直後、ユーザーが 本当？ と尋ね直したところ、実際は ActiveModel::UnknownAttributeError が発生する、と認めた件などがあります。
裏取りを忘れていないかを自問自答させる
これは Hook での直接検出が一番難しいタイプです。「Claude がこれから誤った断定をしようとしているか」をリアルタイムに見抜くには、その誤りを Claude 自身があらかじめ認識している必要があります。ここに構造的な難しさがあります。
そこで採用したのは、毎回の応答ごとに Claude に直前の発言を自己レビューさせる Stop hook です。具体的には次のように動かします。
- 短い応答 (60文字未満、進捗報告など) はスキップ
- それ以外の応答にはチェックリストをフィードバックとして注入
- コードの状態 (実装済みか未実装か、引数の意味など) を断言したか？ 該当ファイルを Read や Grep で確認したか？
- API・ライブラリの挙動を断言したか？ ソースやドキュメントで確認したか？
- 既存パターン (親クラスのデフォルト、慣習) を前提に話したか？
- 推測を確証ある言い切りのように書いていないか？
- 当てはまる場合は Read や Grep、WebSearch などで裏取りしてから訂正、推測の場合は (未確認ですが) と明示してから続行する
考え方は、ユーザーが 本当？ と聞き直す前に、Claude 自身に 本当に？ を問わせる、ループの先回りです。
試験運用としての位置付け
完全な解決策ではなく、試験運用としての導入です。1ヶ月で146件発生していたというベースラインに対して、Hook 導入後にどう動くかを観測して継続・絞り込み・撤去を判断する計画です。あらかじめ計測できる状態を整えておくことで、こうした試験運用も進めやすくなります。効果が確認できれば継続し、十分な効果が見られなければ対象を絞るか撤去する、といった判断をデータに基づいて行えるため、試行結果も次の改善に活かせます。
ブランチ切り忘れをユーザーが指摘する必要をなくした
これは比較的細かい改善ですが、発見に至った流れに重点を置いて、改善事例とあわせてご紹介します。
複数のユーザーが、同じ前置きを繰り返していた
ログを横断的に見たところ、複数の開発者がブランチに関するプロンプトを書いていました。約1ヶ月で集計しただけでも 65件 にのぼります。実際の発言そのままは載せられないので、たとえば次のようなものです。
- 今のブランチから新しいブランチを生やして… (作業開始前の明示)
- master からブランチを切って対応してみてください (依頼の前置き)
-
作業ブランチを切って
/create-pr(定型ワークフローの冒頭) - すでにブランチは切ってるんでしたっけ？ (Claude の認識を照合)
注目したいのは、これらの指示の一部が、スラッシュコマンドやスキルのテンプレート冒頭に固定文として組み込まれていた点です。私自身、以前から自分のスキルに ブランチ切ってから と組み込んでいましたが、ログを見ると、同じ場面で似た前置きを書いている人が他にも複数いました。それぞれの開発者が、同じ問題に対して別々の工夫で対処していた ことになります。
ですが、各自の工夫だけではカバーしきれない上に、こうした細かい工夫に注意を取られてしまう状態には改善余地があります。Push protection があるもののロスは発生しますし、Claude Code を気にかける必要も出てくるため、Hook を使い対策しました。
PreToolUse Hook で master / main への直接コミットを止める
各自のスラッシュコマンドやスキルに分散していた ブランチ切ってから という前置きを、組織共通の1つの Hook にまとめました。Claude Code の PreToolUse hook を使い、git commit 系のコマンドが master または main ブランチで実行されようとした瞬間にブロックして、Claude にブランチを切るよう促します。これで、ユーザーは前置きを書かなくても、Claude 自身が気付いて作業ブランチを切るようになります。
ログ集約の仕組み
AI コーディングツールには、Skill / Hook / MCP / エージェント / プロンプト / システムプロンプトなど、調整できる打ち手のレイヤーが大量にあります。Hook が便利、といった記事もよく目にするようになりました。
こうした打ち手は、それぞれ単体でも非常に強力です。それを組織全体の生産性につなげるには、どの問題に対してどの打ち手を入れるべきかを見極める必要があります。個人の工夫や勘に閉じず、組織共通の改善として育てていくためには、まず Claude Code の使われ方を観察できる仕組みが要ると感じています。
これは、DevEx チームが目指す「開発者体験を向上させる」「開発組織のパフォーマンスを向上させる」という役割とも直結しています。AI コーディングで起きる細かな詰まりを、各開発者のプロンプトやローカル設定に閉じず、組織共通の仕組みとして取り除いていくことは、まさに開発者体験の改善です。
DevEx を含め、組織としてログを見て課題を抽出し、共通 Hook や設定として横展開し、効果観測まで担う例は珍しいのではないでしょうか。
技術的な設計は、次の流れです。
- 各リポジトリに設定した Stop hook が、セッション停止時に Claude Code の transcript を取り出します
- 暗号化した transcript ファイルを、専用の集約リポジトリにコミットして push します
- 集約リポジトリでは、1セッション=1ファイルとして暗号化された状態のまま蓄積します
- 復号に必要な秘密鍵は、Claude Code のログ分析や改善のノウハウを持つ専任エンジニアだけが管理します
この仕組みを使って、改善サイクルを回します。Claude Code のログ分析や改善のノウハウを持つ専任エンジニアである筆者 (developer) がログを復号し、パターンを抽出します。ログの量も膨大なため、Claude に問題点の候補を広く抽出させるなど、AI を前提にした分析を日常的に行っています。見えてきた問題に対して打ち手を設計し、組織共通の Hook やスラッシュコマンド、CLAUDE.md として配布して、現場の Claude Code に戻します。導入後も同じログで効果を観測し、継続・絞り込み・撤去を判断します。これで 観察 → 打ち手 → 計測 → 次の改善 のサイクルを回すことができます。
目指したことは3つです。(a) 開発者は普段の作業を一切邪魔されない こと、(b) ユーザー発言を含む生ログを平文のまま中央集約しない こと、(c) 集めて終わりにしない ことです。以下、3つの観点で順に見ていきます。
開発者に追加作業を求めない
組織共通の設定に Stop hook を設定しています。セッションが止まるたびに、Claude Code の transcript を暗号化して専用の集約リポジトリに送る、という流れです。各リポジトリに hook が組み込まれているため、開発者側で追加の設定も許諾フローも要りません。普段通り Claude Code を使うだけで、ログは自動的に集まります。
導入のハードルもできるだけ下げています。追加のライブラリは不要で、GitHub への認証には開発者が普段から使っている gh コマンドを利用する構成にしました。開発者のローカル環境に新しい依存を増やさずに済むため、組織全体へ横展開しやすくなります。
注意したのは、Claude Code 本体の応答を遅らせないことです。Stop hook を同期で走らせると毎ターンの末尾に遅延が乗ってしまうため、暗号化と送信はバックグラウンドに切り離してあります。Claude Code 側からは hook が即完了したように見えるので、ユーザー体験には何の影響もありません。
暗号化したまま集める
transcript にはユーザー発言を含むセッション全文がそのまま入っているため、平文で中央集約するのはリスクが高すぎます。集約リポジトリにコミットして push する以上、そのための書き込み権限を持つ認証情報が必要になり、GitHub では書き込み権限は通常読み取り権限も伴います。平文のまま集めてしまうと、集約リポジトリを読める人や認証情報を扱える範囲に、生ログがそのまま見えてしまいます。
そこでファイルごと暗号化してから送る形にしました。公開鍵だけを各リポジトリの hook に埋め込み、対応する秘密鍵を持つ人だけが復号できる構成です。
集約リポジトリには 1セッション=1ファイルで保存されていきます。秘密鍵は Claude Code のログ分析や改善のノウハウを持つ専任エンジニアだけが管理しており、復号できる範囲も最小限に絞っています。
専任エンジニアが分析と打ち手づくりを担う
集まったログを復号して横断分析するのは、Claude Code のログ分析や改善のノウハウを持つ専任エンジニアです。Claude を用いて ユーザーが詰まった場面 や 繰り返し起きている問題 を抽出し、よくあるパターンが見えてきたところで、人間がそれをどう減らすかの打ち手を丁寧に考えます。打ち手を入れた後の効果も、同じログで継続観測します。
冒頭で紹介した3つの改善も、こうした分析の結果として出てきた打ち手です。「進めて 確認が40%」「本当？ で訂正が146件」「ブランチ前置きが65件」といった数字は、復号ログを Claude にかけて横断集計した結果から出てきています。個々の開発者は分析プロセスを意識する必要がなく、日々の開発に集中したまま、組織全体の改善は別レイヤーで並走していく、という構造になっています。
まだ運用を始めたばかりの段階で、抽出はかなり粗く、打ち手の生成まで自動化するところには至っていません。セッションが途中で諦められる比率、不要な確認の頻度、特定タスクの完了時間、ユーザーがリトライした回数など、継続追跡したい結果指標は複数考えられますが、現時点ではダッシュボードまで揃ったわけではなく、横断観察と打ち手の選定までが回っている段階です。それでも、組織としての打ち手の選び方は明らかに変わってきました。
また、最近の AI エージェントの議論は human in the loop (HITL) こそが次のボトルネック という認識に収束しつつあります。人間が確認に入るたびに、エージェントの処理はそこで待ち状態になります。もちろん判断やレビューが必要な場面は残りますが、単なる承認や定型的な確認まで人間に戻してしまうと、その分だけリードタイムが伸びます。だからこそ、どこに人間が入るべきかを絞り、それ以外は仕組みに任せる設計が重要になります。
Anthropic も Effective harnesses for long-running agents で、長時間動くエージェントには個々のステップの承認ではなく全体の方針に対する承認へとシフトする必要性を述べている通り、どこから人間の介入をなくすか をログで見ながら設計していくことが、組織全体の底上げに繋がる印象です。
なぜこの仕組みにしたのか
ログ起点で改善サイクルを回すというやり方を設計するとき、特に優先したポイントが3つあります。
1. 普段の開発フローを変えないこと
ログ集約の Stop hook も、ログから抽出した Hook / スラッシュコマンド / CLAUDE.md も、すべて組織共通の設定として配布されています。開発者は 最新の master を取り込むだけ で、追加の設定も承認フローもなしに、最新の状態が手元に反映されます。
ログ収集のためにレトロや勉強会で時間を取られることもなく、ベストプラクティスの差分を自分でキャッチアップする手間もありません。余計な負担を意識せず、いつも通りに開発できる 状態を目指しました。
2. 開発者から見れば、自動的に底上げされていること
知らない間に、Claude Code が日々少しずつ賢くなっているような状態を目指しました。
ログから抽出した打ち手は、組織共通の Hook / スラッシュコマンド / CLAUDE.md として自動配布されるため、各自が CLAUDE.md を個別にメンテしたり、勉強会に時間を割いたりする必要はありません。
3. 計測できるからこそ、打ち手を選び試せること
ログは情報の宝庫です。いつ、どの場面で、誰が何に詰まったか が時系列でそのまま残っているため、実態を高い解像度で把握できます。
打ち手の効果も、同じように観測できます。確認質問の頻度が下がったか、ブランチ切り忘れが消えたか、自己レビューで前言撤回がどの程度減ったかがデータでわかるため、仮説 → 打ち手 → 計測 → 次の仮説 という改善サイクルを、組織として回せる状態になります。
それだけでなく、まだ手をつけていない課題に、どれくらいのインパクトが見込めるか も、同じログから見積もれます。「進めて 確認が40%、Hook で省略すれば月およそ100時間分の承認待ちが浮く試算」「本当？ で訂正が約150件」「ブランチ前置きが60件以上」といった数字も、すべてここから出てきたものです。組織全体での規模感が事前に見えているからこそ、どこから手をつけるかを感覚ではなく規模で決められます。計測できるからこそ、組織にとって効く打ち手に辿り着くことができます。
まとめ
今回の取り組みで大切だったことは、Claude Code のログを集めること自体ではなく、開発者の普段の作業を邪魔せず、安全に集め、改善に戻せる形にしたことです。
具体的には、Stop hook の処理をバックグラウンドに切り離してユーザー体験を遅らせないこと、transcript を平文で集約せず公開鍵で暗号化してから送ること、集めたログを専任エンジニアが分析して共通 Hook や設定として横展開し、効果観測まで続けることを重視しました。これにより、個人の工夫に閉じがちな AI コーディングの改善を、組織として回せる状態に近づけています。開発者に追加の負担をかけず、仕組みとして開発者体験を底上げしていくという意味でも、DevEx らしいアプローチを取れたと感じています。
実際にログから見えてきた課題は、いずれも human in the loop をできるだけ減らす ことに関係していました。進めて とだけ返す確認、本当？ と聞き直す押し戻し、ブランチ切り忘れの指摘は、本来 AI が自分でケアできる余地のある場面です。こうした小さな詰まりを1つずつ仕組みに置き換えることで、ユーザーが画面に張り付かなくても Claude が止まりにくい状態に近づけられます。
長期駆動 (long-horizon agent) が成立する領域では、人間は対話のループから抜け出してエージェントを走らせるだけで済みます。プロダクト開発はまだそこに届いていませんが、せめて人間がループの中で繰り返し詰まっている小さなポイントを、データ起点に1つずつ潰していくことはできます。Claude Code のセッションログを軸にすれば、その小さなポイントが量的に見えてくるので、組織として優先順位をつけて取り掛かれます。
この記事が、皆さまのチームでの AI 運用の参考になれば幸いです。
最後までお読みいただき、ありがとうございました！
Discussion