はじめに - Ask モードへの誤解
GitHub Copilot Chat を使い始めたとき、私は Ask モードを「技術的な質問に答えてくれるツール」だと思っていました。わからないことをググる代わりに、Copilot に聞く。それだけのツールだと考えていたのです。
しかし、以下の記事を読んで、その認識が根本から覆されました。
この記事で知ったのは、Ask モードの真価は単なる Q&A ではなく、リポジトリ全体を調査・分析するツールとしての能力にあるということでした。同じような誤解をしている方もいるのではないでしょうか。この記事では、私の気づきを共有したいと思います。
私が抱いていた誤解
Ask モードは「調べ物ツール」?
最初、私は Ask モードをこのように使っていました。
- 「この API の使い方は?」
- 「このエラーメッセージの意味は?」
- 「この技術の概要を教えて」
確かに便利です。しかし、これでは Google 検索や Stack Overflow と大差ありません。Ask モードを、ただの「AI 版 Google」として使っていたのです。
本当の力に気づいていなかった
実は、@workspace メンションを使えば、プロジェクト全体のコンテキストを理解した上で回答してくれるのです。この強力な機能を、私は見逃していました。正確には「知ってはいたけれど、その価値を理解していなかった」のです。
リンク先の記事から学んだこと
Ask モードの真価 - リポジトリ調査ツール
記事を読んで、Ask モードの本質的な価値を理解しました。それは以下のような能力です。
- リポジトリ全体の構造を把握できる
- ファイル間の依存関係を理解できる
- 設計思想やアーキテクチャを読み解ける
- 新規プロジェクトへのオンボーディングを劇的に加速できる
これは、単なる技術的な Q&A とは次元が違います。
新規プロジェクトにアサインされたときの強力な味方
特に威力を発揮するのは、初めて触るコードベースに対してです。例えば、こんな質問ができます。
- 「@workspace このリポジトリの目的を README から要約してください」
- 「@workspace src/ ディレクトリの役割は?」
- 「@workspace ユーザー認証機能の実装がどのファイルに分散しているか教えて」
- 「@workspace このバグレポートに関連しそうなファイルを列挙して」
こうした質問により、何時間もかかっていたコードベースの理解が、わずか数分で大枠を掴めるようになります。
ただし、盲信は禁物
調査結果をそのまま信じてはいけない
ここで重要な注意点があります。Ask モードの回答は非常に有用ですが、それをそのまま鵜呑みにするのは危険です。
重要なのは、Ask モードを情報収集のための起点として使うことです。つまり、
- AI の回答から手がかりを得る
- 具体的なファイルやコードを自分の目で確認する
- 複数の視点から検証する
- 最終的には自分の理解として消化する
Ask モードは「答え」を与えるツールではなく、「どこを見ればいいか」という探索の出発点を教えてくれるツールです。これを理解してから、私の Ask モードの使い方は大きく変わりました。
深く考えると見えてくる流れ - Ask → Plan → Agent
Ask モードでの調査が起点
Ask モードでリポジトリを理解した後、次に何をすべきでしょうか?
ここで登場するのが Plan モードです。Ask モードの調査結果を、実装につなげる橋渡しをしてくれます。
Plan モードの位置づけ
Ask モードで得た情報を元に、実装計画を立てるのが Plan モードの役割です。
従来のワークフロー：
- Ask モードで調査・質問
- 自分で設計・計画を立てる（ここが大変）
- Edit/Agent モードで実装
Plan モードを活用したワークフロー：
- Ask モードで調査・質問
- Plan モードで調査結果を元に実装計画を立てる（AI がサポート）
- Agent モードで計画に基づいて実装
この違いは大きいです。特に、複雑な要件や大規模な変更を行う際に効果を発揮します。
Plan モードは実装計画特化のカスタムエージェント
技術的に興味深いのは、Plan モードの実装方法です。これも記事で知ったのですが、
- 他のモード（Ask/Edit/Agent）: intent ベースのアーキテクチャ
- Plan モード: カスタムエージェントとして実装
この設計の違いが、Plan モードに独自の強みをもたらしています。
- 要件を構造化し、段階的に詳細化できる
- 対話を通じて計画を洗練できる
- 不明点を質問しながら改善していける
- 実装前にレビューや合意形成が可能
つまり、Plan モードは単なる「計画書生成ツール」ではなく、対話を通じて計画を育てていくパートナーです。
Ask の代わりに Plan を使う利点
なぜ Plan モードを使うべきなのか?
Ask モードで調査した後、直接 Agent モードで実装に入るのではなく、Plan モードを挟むことで以下のメリットがあります。
1. 要件の明確化
曖昧な要件を明確なステップに分解してくれます。
- 実装の見落としを防げる
- チームメンバーとの認識合わせが容易になる
- 手戻りを大幅に減らせる
私の経験では、「なんとなくわかった気になって実装を始める」ことで、後で大きな手戻りが発生することがよくありました。Plan モードはこれを防いでくれます。
2. 反復的な改善
対話を通じて計画を洗練できます。
- 不明点を質問しながら段階的に詳細化できる
- 実装前にレビューや合意形成ができる
- AI と人間が協働して最適な計画を作れる
これは、一人で「うーん、どうしよう」と悩むより、はるかに効率的です。
3. GitHub Issue/PR との連携
生成された計画を、そのまま開発プロセスに活用できます。
- plan.md を Issue に添付して議論できる
- PR の説明文として活用できる
- チーム全体で計画を共有できる
ドキュメント作成の手間も省けて一石二鳥です。
Plan モードのカスタムエージェントとしての強み
intent ベースの制約を受けないため、より柔軟な計画立案が可能です。
- プロジェクト固有のコンテキストを深く理解できる
- 複雑な要件でも段階的に対応できる
- 実装の実現可能性も考慮した計画を立てられる
これは、汎用的な Ask モードでは難しい、実装に特化した深い思考を提供してくれます。
実践的な使い分け
私が考える理想的なワークフロー
新規プロジェクトや大きな機能追加に取り組む際、私は次のような流れで進めるようになりました。Ask モードの真価を理解してから、開発のスピードと品質が向上したと実感しています。
Step 1: Ask モードでリポジトリ調査
@workspace メンションを使って、コードベース全体を理解します。
- アーキテクチャの把握
- 既存の実装パターンの理解
- 関連するファイルやモジュールの特定
重要: ここで得た情報は仮説として扱い、必ず自分の目でコードを確認します。Ask モードは「地図」を提供してくれますが、実際の「探検」は自分で行う必要があります。
Step 2: Plan モードで実装計画を立てる
Ask モードで得た理解を元に、具体的な実装計画を作成します。
- 変更が必要なファイルのリスト
- 実装の優先順位
- テスト戦略
- 考慮すべきエッジケース
ここで重要なのは、対話を繰り返しながら計画を洗練していくことです。最初の計画は完璧である必要はありません。
Step 3: Agent モードで実装
確定した計画に基づいて、Agent モードに実装を依頼します。
- 計画が明確なので、Agent モードの精度が上がる
- 手戻りが少なくなる
- レビューも効率的になる
このワークフローを採用してから、「実装してみたら想定と違った」という事態が激減しました。
まとめ - Ask モードの再発見
Ask モードは「調べ物ツール」以上の存在
この記事で共有したかったのは、私自身の気づきと、同じ誤解をしている方への情報共有です。
- Ask モードを「単なる Q&A ツール」だと思っていた
- 実際はリポジトリ調査の主要ツールだった
- @workspace メンションで真価を発揮する
もしあなたも Ask モードを「技術的な質問に答えてもらうだけ」に使っているなら、ぜひ @workspace メンションを試してみてください。見える世界が変わるはずです。
調査から実装までのシームレスな流れ
Ask → Plan → Agent という流れを意識することで、開発効率が大きく向上しました。それぞれのモードの役割を理解することが重要です。
- Ask: リポジトリ全体を理解する（調査フェーズ）
- Plan: 調査結果を元に実装計画を立てる（設計フェーズ）
- Agent: 計画に基づいて実装を進める（実装フェーズ）
この3つは、それぞれ独立したツールではなく、連携して使うことで最大の効果を発揮します。
最後に - 盲信せず、検証を忘れずに
AI は強力なツールですが、完璧ではありません。常に以下を心がけています。
- 調査結果は必ず自分の目で検証する
- 計画は人間がレビューする
- 実装されたコードもテストとレビューを行う
Ask モードは「答え」を与えるツールではなく、「正しい質問」をするための手がかりを提供してくれるツールです。この理解が、効果的な活用への第一歩だと思います。
参考リンク
この記事を書くにあたって参考にした記事です。詳しく知りたい方はぜひご覧ください。