👋 はじめに
私は普段、Webアプリ・Windowsクライアントアプリ・クラウド基盤を扱うプロダクト開発チームで、開発兼チームマネージャーのような立ち回りをしています。日々の仕事は「自分で全部コードを書く」フェーズをとっくに過ぎていて、実際のところは 調べる・答える・レビューする・仕組みを作る の比率がずっと高い。
そんな私が、ここ1〜2か月でAIコーディングエージェントに実際に投げていた業務を棚卸ししてみたら、想像以上に「コード生成以外」の使い方が多いことに気づきました。この記事では、その実例をカテゴリ別に紹介します。
🛠️ 前提：私の使い方
- AIエージェントはIDE統合型のものを利用（プロジェクトのソースコード全体を文脈として読ませられるタイプ）
- 複数リポジトリ（Webアプリ、クライアントアプリ、運用ツール群）を横断して質問する
- MCP（Model Context Protocol）でブラウザ操作やデザインツール連携も併用
- 定型作業は「スキル」や「フック」として仕組み化して再利用
ポイントは、AIに自社コードとドキュメントを丸ごと読ませたうえで会話していること。これが「コードを書く道具」から「業務の相棒」へ変わる境目でした。
💬 実例1：外部委託先・他部署からの技術質問への一次回答
一番件数が多かったのがこれでした。
委託先や他チームから飛んでくる質問は、たいてい「この機能って内部でどう動いてるの？」「この仕様の根拠は？」というもの。従来なら該当ソースを自分で追い、設計ドキュメントやADR（Architecture Decision Record）を引っ張り出して回答していました。
今はこうしています。
「○○機能について質問が来ている。ソースコード・ADR・仕様書を根拠に回答の下書きを作って」
AIがリポジトリ内のコードと設計文書を横断的に読み、根拠となるファイル名を添えて回答案を出してくれます。私はその内容の妥当性をチェックして、必要なら補足して返すだけ。
📌 学び
- 「根拠を示して」と指示するのが重要。ソースの該当箇所を引用させることで、回答の裏取りコストが激減する
- AIの回答をそのまま送らない。一次回答の生成までがAIの仕事で、最終判断は人間が持つ
👀 実例2：コードレビュー / PRレビュー（マネージャー視点）
レビュー依頼が重なると、どうしても後回しになりがちです。そこでAIに「先にざっと見て」を頼むようになりました。
「開発リーダーの観点で、次のPRをレビューして」
観点を明示するのがコツです。「開発リーダー観点」「セキュリティ観点」「可読性重視」など役割を与えると、指摘の粒度が変わります。命名、責務分割、既存パターンとの整合、テスト漏れあたりを一通り洗ってくれるので、私は本質的な設計判断のレビューに集中できます。
📌 学び
- AIレビューは「一次スクリーニング」。定型的な指摘はAIに任せ、人間はアーキテクチャや業務ロジックの妥当性に注力する
- レビュー観点をプロンプトで役割として渡すと、出力の質が安定する
🔍 実例3：仕様の「逆引き」壁打ち
「この機能の仕様、ドキュメントが古くて当てにならない」――あるあるです。
こういうとき、AIに 実装コードから仕様を逆算させる のが効きます。
「この画面の入力チェック仕様を、実装コードを根拠に整理して」
コード上の分岐ロジックやバリデーションを読み取り、仕様の形に起こしてくれます。ドキュメントとコードの乖離を発見するきっかけにもなり、「ドキュメント側が間違っていた」というケースを何度も拾えました。
📌 学び
- 一次情報（コード）を正としてAIに整理させると、形骸化したドキュメントの棚卸しにも使える
🧭 実例4：新機能の検討・設計フェーズ
新機能は、いきなり実装ではなく検討から入ります。認証方式の変更、管理対象の絞り込み機能、画面の入力項目設計など、要件の解像度を上げる段階でAIを壁打ち相手にします。
「この新機能を入れると、既存のどこに影響が出る？ 影響範囲を洗い出して」
既存コードを踏まえた影響範囲の洗い出しや、実装方針の複数案出しをやらせると、検討の抜け漏れが減ります。設計ドキュメント（要件・設計・タスク）の下書きまで一気に作らせることもあります。
📌 学び
- 設計フェーズこそAIの価値が高い。「作る前に考える」を高速で回せる
- 影響範囲の洗い出しは、人間だと見落としがちな箇所をAIが機械的に拾ってくれる
🤖 実例5：MCPでブラウザ操作・プロトタイピング
コードを書く以外で一番「未来を感じた」のがMCP連携です。
- ブラウザ操作MCP：ローカルで動かしたWebアプリに実際にログインし、画面遷移を自動でテスト。「この操作でちゃんとログインできるか確認して」と頼むと、AIがブラウザを操作して結果を返す
- デザインツールMCP：デザインデータからプロトタイプUIを生成し、顧客提示用の叩き台を短時間で用意
「AIが手を動かして確認する」領域に入ってきた感覚があります。
📌 学び
- MCPは「AIに現実世界の操作をさせる」拡張。テストやプロトタイピングの初速が段違いになる
☁️ 実例6：クラウド運用の調査
運用フェーズの「調べもの」もAIに投げています。
- 監査ログから特定リソースの作成者を特定する
- サーバーレス関数の構成確認や、監視ツールで特定要件が達成できるかの調査
- 疎通先環境の切り替え設定の確認
「このログから作成者を調べて」のような調査依頼は、コマンドの組み立てから結果の解釈までまとめて任せられます。
📌 学び
- 運用調査は「コマンドを思い出す」コストが地味に高い。そこをAIが肩代わりしてくれる
📝 実例7：ドキュメント・技術記事づくりと自動レビュー
ドキュメントや技術記事も、AIと一緒に書いています。さらに一歩進めて、フックで自動レビューを仕込みました。
たとえば「記事ファイルを保存したら、法務観点・表記ルール観点で自動チェックを走らせる」といった仕組みです。書く→保存→自動レビュー、が回るので、公開前のチェック漏れが減ります。
📌 学び
- 繰り返す品質チェックは、フックで自動化してしまうのが正解
- 「書く」だけでなく「書いたものを継続的に点検する」までAIに任せられる
♻️ 実例8：スキル化による定型作業の再利用
同じ種類の作業を繰り返すなら、その手順自体をAIに教え込んでスキルとして保存しておけます。
- 環境構築の手順
- 特定フォーマットのテスト項目書づくり
- 仕様書のフォーマット変換
一度スキルにしておけば、次回は「あのスキルでやって」の一言で同じ品質の作業が再現されます。属人化していたノウハウを、チームで共有できる資産に変えられるのが大きい。
📌 学び
- 「毎回同じ説明をしている」と感じたら、それはスキル化のサイン
💡 AIに任せてみて分かったこと
-
AIの主戦場は「コード生成」ではなく「文脈理解」
自社コードとドキュメントを丸ごと読ませられると、質問対応・調査・レビューの初速が劇的に上がる。 -
役割と観点を与えると出力が安定する
「開発リーダーとして」「根拠を示して」の一言で、回答の質が別物になる。 -
AIの出力は一次成果物。最終判断は人間が持つ
特に社外へ出す情報や設計判断は、人間のレビューが前提。 -
繰り返す作業は仕組み化する
スキル・フックに落とし込むと、個人の効率化がチームの資産になる。
🎯 まとめ
AIコーディングエージェントは、もはや「コードを書く道具」という枠に収まりません。私の直近の使い方を棚卸ししてみると、実際には 質問対応・レビュー・仕様調査・設計・運用調査・ドキュメント・自動化 と、開発ライフサイクルのあらゆる場面に食い込んでいました。
「コードを書かせる」から一歩踏み出して、自分の業務そのものをAIと一緒に回す。その視点で使い方を見直すと、まだまだ任せられる仕事が眠っているはずです。
🎁 おまけ（オチ）
……ところで、この記事で紹介した「実例」たち。どうやって思い出したと思いますか？
この記事は、AIエージェントがローカルに残していた私自身のセッション履歴（対話ログ）を、AIに読み込ませて自動生成しています。
「最近どんな質問を投げてたっけ？」をAIに棚卸しさせ、カテゴリに分類させ、社外向けに固有名詞をぼかし、記事の形にまとめてもらう――つまり、AI業務活用の記事を、AI業務活用そのもので書いたというオチでした。
自分の作業履歴すら、AIにとっては立派な一次情報。使わない手はありません。
AIエージェントの対話履歴はローカルに保存されており、それを入力として本記事を生成しました。保存されるファイルの中身には業務情報が含まれ得るため、履歴ファイル自体を社外に共有することはしていません。
本記事に掲載している内容は、私個人の見解であり、所属する組織の立場や戦略、意見を代表するものではありません。