こんにちは。認証チームのいまひろです。
以前の記事で、Claude Codeのプラグインによる開発プラクティスのコード化や、セッションの自動記録による「航海日誌」の仕組みについて紹介してきました。
私たちのチームでは、モブ作業を主体とした開発スタイルをとっていますが、Claude Codeのセッション記録（航海日誌）を導入したことで、チームとして、いつ何をしたかがある程度見えるようになりました。しかし、ここで新たな課題が浮上しました。
Claude Codeを介さずに行った作業は、記録に残らない。
当たり前のことですが、これが意外と大きな問題でした。
今回は、この問題を解決するための取り組み——チームのあらゆる作業をClaude Codeを通じて行うという方針と、それによって実現した開発プロセスのほぼ全工程の可視化について書きたいと思います。
「見えない作業」という課題
航海日誌の仕組みは、Claude Codeのセッション内で行われた操作をJSONLログから分析し、構造化されたレポートとして記録するものです。コード編集、Git操作、Jiraチケットの更新、調査作業——セッション内で行われたことは、ツール呼び出しの種類と時間配分まで含めて自動的に記録されます。
しかし、開発者がターミナルで直接コマンドを叩いたり、ブラウザで手動テストを行ったりする作業は、この記録から抜け落ちます。
具体的には、以下のような作業が「見えない」状態でした：
- ローカルリソースの操作: MySQL、DynamoDB、SQSなど、ローカル開発環境のミドルウェアの状態確認やデータ操作を、開発者がCLIで直接実行
- Dockerログの確認: アプリケーション実行時のログ調査を、開発者が
docker logsコマンドで直接確認 - ブラウザでの手動テスト: 開発完了後の確認テストを、開発者が手動でブラウザを操作して実施
- 調査作業とドキュメント化: ブラウザで技術調査を行い、結果をWikiにまとめるといった一連の作業
- テスト結果の記録: テストの合否はチェックリストにチェックを入れるのみで、テスト過程の詳細な証跡が残らない
航海日誌のデータをもとにチームの定量・定性分析を行おうとしても、これらの「見えない作業」が存在する限り、データの網羅性に疑問が残ります。記録されている作業だけを見て「チームの生産性」を語ることはできません。
方針：すべての作業をClaude Code経由にする
そこでチームとして、できる限りすべての作業をClaude Codeをインターフェースとして実行するという方針を立てました。
これは単に「AIに任せる」ということではありません。人間が行っていた操作をスキル（プラグインのコマンド）として定義し、Claude Codeを通じて実行することで、作業の実行と記録を同時に実現するということです。
従来: 開発者 → ターミナル/ブラウザ → 作業完了（記録なし） 現在: 開発者 → Claude Code（スキル実行） → 作業完了（自動記録）
この方針のもとで、大きく分けて3つの領域でスキル化を進めました。
実践①：ローカルリソース操作・ログ調査のスキル化
背景
私たちのローカル開発環境では、Docker上にMySQL、DynamoDB、SQSなど複数のミドルウェアが動いています。開発やデバッグの過程で、DBのテーブル内容を確認したり、キューの状態を見たり、アプリケーションのDockerログを調査したりする操作は日常的に発生します。
これまでは、開発者が aws dynamodb scan や docker logs 、 mysql といったコマンドを直接ターミナルで実行していました。特に厄介だったのが、たまにしか使わないコマンドのオプションやエンドポイント指定を、毎回思い出したり調べたりする煩わしさです。「あのテーブルをスキャンするコマンド、どう書くんだっけ？」「ローカルDynamoDBのエンドポイントは --endpoint-url で指定するんだったか？」——こうした些細なストレスが積み重なっていました。
スキル化のアプローチ
これらをClaude Codeのスキルとして定義しました。例えば、DynamoDBのテーブルスキャンやアイテム削除、Dockerコンテナのログ調査などを、それぞれ専用のスキルにしています：
/db-scan [どのテーブルに対して何を取得したいか] /db-delete [どのテーブルに対して何を削除したいか] /docker-investigate [どのようなログ出力を知りたいか]
スキルの中では、ローカル環境のエンドポイント、リージョン設定、コンテナ名の命名規則など、環境固有の情報をあらかじめ定義しておき、開発者は「何を確認したいか」だけを自然言語で指示すれば良い状態にしました。
これにより：
- 操作の標準化: チームメンバー全員が同じ方法でリソース操作を行う
- 操作の記録: いつ、どのリソースに、どんな操作を行ったかがセッションログに残る
- コンテキストの保持: 調査結果をもとにした次のアクション（コード修正、チケット更新など）が同一セッション内でシームレスにつながる
- 認知負荷の軽減: AWSコマンドのオプション指定やDockerのコンテナ名など、覚えておく必要のない情報から解放される
小さな改善に見えますが、「ちょっとDBを確認する」「ログを見る」という何気ない作業が記録から消えなくなったこと、そしてコマンドを思い出す手間がなくなったことの2つのメリットは、日々の開発体験を確実に改善しています。
実践②：調査・ドキュメント化作業のスキル化
背景
開発作業の中には、ブラウザで技術情報を調べ、その結果をWikiにまとめるという作業もあります。例えば、外部サービスの仕様調査、障害対応時の状況整理、新しいライブラリの評価などです。
これらの作業は、ブラウザでの閲覧→情報の整理→Wiki記事の作成という一連の流れで行われますが、Claude Codeの外で実施してしまうと、航海日誌には一切記録されません。
スキル化のアプローチ
Web検索やページの取得をClaude Codeのセッション内で行い、調査結果をそのままWikiページとして作成・更新するスキルを用意しました。
これにより、「何を調べて、どんな結論に至り、どこにまとめたか」がセッション記録に残るようになりました。調査のプロセス自体が可視化されることで、後から「なぜこの判断をしたのか」を追跡できるようになっています。
実践③：Gherkinテストの自律実行・レポート生成のスキル化
これまでの開発フロー
私たちのチームでは、BDD（振る舞い駆動開発）の考え方を取り入れ、Gherkin形式のテストケースを開発工程に組み込んでいます。チケットの完了条件を満たすためのGherkinテストケースをまず作成し、それに基づいて実装を行い、最後にテストを実施して合格することが求められます。
これまでの流れは以下の通りでした：
1. Gherkinテストケースの作成 ← Claude Code 2. チケットの実装 ← Claude Code 3. テストの実施 ← 開発者が手動でブラウザ操作 ← ここが「見えない」 4. テスト結果の記録 ← チェックリストにチェックを入れるのみ ← 詳細な情報が残っていない
ステップ3と4が、Claude Codeの記録から完全に抜け落ちていました。テスト結果の証跡としてはチェックリストへのチェックのみが必須とされており、テストの過程——どの画面で何を確認し、どんな状態だったか——は記録に残りませんでした。
chrome-devtools MCPによるブラウザ自動テスト
今回、chrome-devtools MCP を活用し、Gherkinテストの実施自体をClaude Codeのスキルとして実装しました。
chrome-devtools MCPは、Claude Codeからブラウザを直接操作できるようにするMCPサーバーです。これにより、ページ遷移、フォーム入力、ボタンクリック、画面の確認といったブラウザ操作を、Claude Codeのセッション内で実行できます。
テスト実施スキルの仕組み
テスト実施スキルは、以下のステップで動作します：
1. テストシナリオの分類
Gherkinのfeatureファイルを読み込み、各シナリオを実行方法で分類します：
| 分類 | 実行方法 | 例 |
|---|---|---|
| ブラウザ自動テスト | chrome-devtools MCPで自動実行 | ログイン画面の操作、設定変更の確認 |
| DB検証 | SQLクエリで確認 | データの永続化確認、ステータス変更の確認 |
| 手動確認 | ユーザーに確認を依頼 | メール送信の確認、外部APIとの連携 |
すべてのテストを自動化するのではなく、自動化できるものとできないものを明確に分離するのがポイントです。
2. シナリオごとの実行とスクリーンショット取得
ブラウザ自動テストでは、Gherkinの各ステップ（Given / When / Then）に沿って操作を実行し、重要なポイントでスクリーンショットを取得します。
Scenario: ユーザーがプロフィールを更新できること Given ユーザーがログイン済みであること → ログイン操作を実行 When プロフィール編集画面で名前を変更する → 📸 操作時のスクリーンショット Then 変更が保存されていること → 📸 確認時のスクリーンショット
スクリーンショットは証跡として、テストリポジトリ内の所定のディレクトリに保存されます。
3. テストレポートの自動生成
テスト完了後、以下の内容を含むMarkdownレポートを自動生成します：
## テスト実施サマリー | 項目 | 結果 | |------|------| | 実施日 | 2026-04-10 | | 対象チケット | PROJ-1234 | | 全シナリオ数 | 8 | | Pass | 8 | | Fail | 0 | ## シナリオ別結果 | # | シナリオ | 実行方法 | 結果 | |---|---------|---------|------| | 1 | ログインできること | ブラウザ自動 | ✅ Pass | | 2 | 不正パスワードでエラーになること | ブラウザ自動 | ✅ Pass | | ... ## 詳細 ### シナリオ1: ログインできること **実行方法:** ブラウザ自動テスト #### When: ログインフォームに正しい認証情報を入力する  #### Then: ダッシュボードが表示されること  **結果:** ✅ Pass
このレポートとスクリーンショットは、テストリポジトリにコミット・プッシュされ、PRとして残ります。
4. 失敗時のフィードバックループ
テストが失敗した場合、スキルは以下の情報をレポートに記録します：
- 期待された結果と実際の結果
- 失敗時のスクリーンショット
- 推定される原因
そして、開発者に対して次のアクションを確認します——実装を修正するか、テストケースを見直すか、再実行するか。このフィードバックもClaude Codeのセッション内で行われるため、当然ながら航海日誌に記録されます。
実現された開発フロー
テスト実施のスキル化により、開発フローは以下のように変わりました：
1. Gherkinテストケース作成 ← Claude Code（スキル） 2. チケットの実装 ← Claude Code 3. テストの実施 ← Claude Code（スキル） ← 新規スキル化！ 4. テストレポート生成 ← Claude Code（スキル） ← 自動生成！ 5. テスト結果のコミット ← Claude Code（スキル） ← 自動コミット！
開発プロセスのほぼ全工程が、Claude Codeをインターフェースとして実行されるようになりました。
チーム開発への展開で意識したこと
個人の環境でClaude Codeを便利に使うことと、チーム全体で統一的に使うことには大きなギャップがあります。今回のプラグインでのスキル化においても、チーム開発ならではの工夫が必要でした。
1. 環境差異の吸収
ローカル開発環境の構成はメンバーによって微妙に異なります。DB操作のスキルでは、エンドポイントやポート番号などの環境固有の設定をスキル内で吸収し、メンバーは「何を行いたいか」だけを指定すれば良いようにしました。
2. テスト実行の前提条件の明文化
ブラウザ自動テストを行うには、ローカル開発環境が起動している必要があります。スキルは実行前に環境の起動状態を確認し、未起動であればその旨を開発者に通知します。「動かない」というトラブルを未然に防ぐ設計です。
3. 証跡の標準化
テストレポートのフォーマット、スクリーンショットの命名規則、保存先のディレクトリ構造——これらをスキル内で固定することで、誰がテストを実施しても同じ形式の証跡が残ります。モブ作業でメンバーが入れ替わっても、レポートの読み方に迷うことはありません。
4. 人間の判断が必要な部分の明確な分離
すべてを自動化するのではなく、「ここは人間が確認する必要がある」という箇所を明確にスキル内で定義しました。メール送信の確認やモバイルアプリとの連携テストなど、ブラウザ操作だけでは完結しない部分は、スキルが開発者に確認を求めます。
可視化がもたらす効果
すべての作業をClaude Code経由にすることで、航海日誌の記録がより網羅的になりました。これにより、以下のような効果が期待されます。
定量データの精度向上
セッションごとに記録される「アクティブ時間」「ツール使用回数」「作業カテゴリ別の時間配分」——これらのデータが、チームの実際の作業をより正確に反映するようになりました。「テスト実施に思ったより時間がかかっている」「DB操作の頻度が特定のフェーズで増える」といった気づきが、データから得られるようになります。
テストの証跡の質的変化
従来のテスト証跡は、チェックリストにチェックを入れることだけが必須でした。テストに合格したことは分かりますが、「どの画面でどんな操作をして、どんな状態を確認したのか」というプロセスは記録されていません。スキル化により、スクリーンショット付きの構造化されたレポートが自動的に生成されるようになりました。チェックリストの「✓」から、再現可能な証跡への質的な変化です。
開発プロセス全体の見通し
チケットの着手からテスト完了まで、ほぼすべてのステップが航海日誌に記録されることで、開発プロセス全体の流れが可視化されました。週次レポートの自動生成と合わせて、「今週チームは何をしていたか」がデータとして把握できるようになっています。
現在の開発プロセスの全体像
ここまでの取り組みを図にすると、以下のようになります：
チケット着手からテスト完了、セッション記録、週次レポートまで——開発プロセスのほぼ全体が、Claude Codeという単一のインターフェースを通じて実行・記録されるようになりました。
まだ残っている課題
もちろん、すべてが完璧に可視化されたわけではありません。
- コードレビュー: PRのレビューはGitHub上で行われるため、レビューコメントのやり取り自体はClaude Codeのセッション外で発生することがある
- 設計議論: ホワイトボードやビデオ通話での設計議論は、Claude Codeの記録には残らない
- 外部サービスとの連携テスト: SaaSの管理画面での設定変更など、ブラウザ自動操作が困難な操作もある
これらについて、無理にClaude Code経由にすることが目的ではありません。記録に残すべき作業と、そうでない作業を見極めながら、データの網羅性を段階的に高めていくことが重要だと考えています。
おわりに
「Claude Codeをチームの統一インターフェースにする」という方針は、一見すると大げさに聞こえるかもしれません。しかし、その本質は作業の実行と記録を一体化するという、シンプルな考え方です。
スキルとして定義されたDB操作やテスト実施は、それ単体では小さな自動化に過ぎません。しかし、航海日誌や週次レポートの仕組みと組み合わさることで、チームの開発活動全体を可視化する基盤になります。
私たちの取り組みはまだ道半ばですが、「開発プロセスの中で、どこが見えていて、どこが見えていないか」を常に意識することが、次の改善への第一歩になると実感しています。
