株式会社パレットリンクの@BaspisKawaEです！
今回は、ChatGPTやMicrosoft 365 CopilotのようなチャットAIを、Claude CodeやCodexのように、雑な依頼からでも必要なファイルを確認しながら調査を進められる状態に近づける方法について考えていきます。
私は現場での実務でもCopilotに細かい作業規則を持たせています。
「これ、運用で何とかならないかな～」と、ファイルの渡し方や確認手順を少しずつ試していったところ、思っていた以上にうまくいきました。
この記事では、そのとき実際に組んだ運用を、順番にほどいてご紹介します。
よろしくお願いします!
対象読者: ChatGPTやMicrosoft 365 CopilotなどのチャットAIを、現場で利用できるエンジニア
前提知識: チャットAIを使った経験、ファイル・ディレクトリ・ログについての基礎知識
この記事で学べること: AIから見えるファイル領域を「作業机」として管理させ、人間がローカルPCから必要な資料を運び込むことで、チャットAIの能力を拡張する方法
目次
- 背景：AI、ちゃんと読んでなくない？
- この記事で作りたい状態
/mnt/dataはAIの作業机になる- チャットAIとローカルPCをつなぐ調査ループ
- 実務で使っている作業規則
- 作業規則は毎回書かない
- 再現用の親プロンプト
- 専用エージェントとの差はどこまで埋まるか
- まとめ
1. 背景：AI、ちゃんと読んでなくない？
チャットAIを現場での開発に使っていると、たまに「いや、それはないでしょふざけないでよ」と言いたくなる場面があると思います。
- 1000行を超えるコードを渡したのに、途中までしか見ずに「未完成のコードです」と言われる
- 10万行を超えるログを渡したのに、序盤の内容にしか触れない
- 複数ファイルを渡したのに、途中から一部を参照しなくなる
- プロジェクト全体の方針を考慮せず、一貫性のない実装を行う
こんなことでは、怖くて怖くて到底使えません。個人開発ならまだしも……。
というわけで、私はこのあたりを「AIの限界」という便利な言葉で片付ける前に、運用で何とかならないかを色々試してみました。
するとかなりの部分が改善したので、その考え方をこの場に書いていきます。
大前提、
あなたはプロのエンジニアです。
というような、ロールプレイプロンプトを紹介するわけではないです。
可能な限り噛み砕いてお話しますが、そこそこPC操作に詳しくないと理解できない内容が含まれてもいるので、頑張って読んでいただけると嬉しいです。
さて、具体的な手法の話に入る前に、考察の土台から整えていきましょう！
まず、何が欲しいか宣言する前に、欲しいものを取得する方法を、手続きとして厳密に定義しておく、というのがAI活用における第一の考え方になります。
たとえば障害調査なら、人間は自然に次のようなことをやりますね。
1. 今ある資料を確認する
2. ログの大きさや対象期間を見る
3. ERRORや例外名を検索する
4. 該当箇所の前後を見る
5. リクエストIDやトランザクションIDを拾う
6. 同じIDを別ログから検索する
7. クラス名が出たらソースへ移る
8. 足りない資料があれば追加で取る
9. 事実と推測を分けて結論を出す
一方、AIには、
このログ見て原因調べて教えて
としか頼んでいないことが多いと思います。
何を得たいのかを宣言しているだけなんですね。
これでも目的は勿論伝わるでしょうが、肝心の調査方法はAI任せです。
これでは出力がブレてしまうに決まっています。
そこで、仕事の内容──何（What）を得たいかの宣言だけでなく、仕事の進め方そのもの──どうやって（How）進めるかの手続きを先に決めておきます。
これ自体は、一般的に普及しているClaudeのSkillなどと同じ、AI活用の基礎の考え方です。
次章では、AIをどんな状態にしたいのかを論じ、その後に具体的な手法に入っていきます！
2. この記事で作りたい状態
さて、先ほど手続きを先に決めるぞ！ と言ったので身構えてしまったかもしれませんが。
この記事で目指すのは、毎回長いプロンプトを「うおおおお！」と書くことではありません。
最終的には、
このログ見て原因調べて～ わけわからーん
このコード直してくれへんか～
このPTの証跡まとめてくれ～い
という宣言型のゆる～い依頼でも、AI側で固定化された手法に従って作業を始めてほしいわけです。
これを実現するために使うのが、チャットAIへアップロードしたファイルが置かれる領域です。
次の章では、その仕組みを見ていきます。
3. /mnt/data はAIの作業机になる
チャットAIにファイルをアップロードすると、そのファイルはAIが扱える実行環境へ渡されます。
私が使っているChatGPTとMicrosoft 365 Copilotでは、アップロードしたファイルを /mnt/data から確認できました。
/mnt/data は、AIにとっての作業机だと考えると取っつきやすいと思います。
ここに置かれたファイルに、AIは自由にアクセスすることができます。
ちょうどあなたが、ご自身のpcのターミナルからlsコマンドを打って、フォルダやファイルを眺めることが出来るのと同じように、
- ファイル一覧を確認する
- サイズや行数を調べる
- ファイル内を検索する
- Pythonなどを使って内容を読む、編集する
- 複数ファイルを比較する
- 調査結果や修正版を新しいファイルとして出力する
- 圧縮してZIPファイルとして出力する
と、そんなことができます。
要点は、この領域の中でのみ、チャットAIは最大の効力を発揮するという点にあります！
領域外のファイルには触れることさえできません。
そこで、人間が必要なファイルを /mnt/data へ運び、AIには作業机の中を厳密に管理させます。
AIには、「自分は作業机の中でいろいろやっているのだ」ということをしっかりメタ認知させます。
たとえば、実際の調査が進んでいくと、作業机にはこんな資料が並びます。
project_tree.txt
編集したいコード.java
画面設計書.xlsx
詳細設計書.xlsx
Powershellの検索結果.txt
このファイル群を、今回の調査に必要な資料一式としてAIに扱わせます。
次の章では、この作業机とローカルPCの間で資料をどう増やしていくかを話します。
4. チャットAIとローカルPCをつなぐ調査ループ
実際の流れはこうです。
この運用では、次に何を調べるかはAIに決めさせます。
人間が担当するのは、AIから直接触れないローカルPC側の操作です。
AIが必要な資料と取得方法を決め、人間は生成されたコマンドを実行して、できたファイルを作業机へ運びます。
AIに調査を考えさせて、人間はアクセス権の壁だけ越えさせる。
これが、この運用の核心です。
図だけだとまだ抽象的なので、次の章ではこのループを安定して回すために、実際にAIへ持たせている規則を紹介していきます！
5. 実務で使っている作業規則
ここからは、前章の調査ループを実際に回すために、私がAIへ持たせている規則を順番に紹介していきます。
まず必要なのは、
- 今、何のファイルを持っているのか
- プロジェクトのどこに何があるのか
- そのファイルを必要な範囲まで読めているのか
この3つをAI自身が把握できる状態です。
ここが整って初めて、「次に何を調べるべきか」をAIへ任せられるようになります。
5-1. 作業机に何があるかはAI自身に確認させる
ファイルをアップロードしたあと、人間側からAIの作業環境を直接覗くことはできません。
せっかくファイルを渡しても、
「今このチャットに何を渡していたっけ……？」
「さっき生成したファイル、まだ残ってる！？」
のような質問をやり始めると、だんだん面倒になってきます。
私は三歩歩くと全部忘れるタイプなので、ここもAIに自動でやらせます。
私の環境では、次のコマンドを実行させて、出力結果を生成されるチャットの最下部に記載させています。
ls -la /mnt/data
そして、ファイルを受け取ったときや重要な成果物を作ったときに、作業机の状態を確認すること自体を規則にしています。
私のCopilotでは、概ね次のような扱いです。
- 添付ファイルを受け取ったら、表示上の抜粋だけで判断しない
-
/mnt/dataに実ファイルがあるか確認する - ファイル名・サイズ・更新日時を確認する
- 重要なファイルを受領・生成したら、もう一度
/mnt/dataを確認する - 見つからないファイルを、存在する前提で扱わない
これだけでも、AIが「過去にあのファイルは受け取ったし、自分は全部ちゃんとわかっているぞ！」と自信を持って話を進めてしまう事故を減らせます。
現行の主要なAIモデル（2026/8月時点）は、前提となるファイルが足りていない場合に、ユーザーに再提出を求める程度の危機管理能力を持っています。
こうして作業机に何があるか分かる状況を作れたら、次はプロジェクトそのものの地図を持たせましょう。
5-2. 最初にプロジェクトの地図を作らせる
コード調査をAIへ任せるなら、個々のソースを渡す前に、プロジェクト全体の構成を見せておくとかなり楽になります。
私が最初に渡すもののひとつが、project_tree.txt です。
Windowsなら、たとえば次のように取得できます。
tree /F /A > project_tree.txt
大きなプロジェクトではそのままだと量が多くなるので、実際には対象ディレクトリを絞ったり、不要なディレクトリを除外したコマンドをAIに作らせます。
そしてその後、その構造が何を意味しているのかまで、AIに整理させます。
たとえば、次のように頼みます。
project_tree.txt を確認してください。
主要なディレクトリとファイルについて、
それぞれ何を担当している場所なのか整理してください。
名前だけでは判断できない場合は、
必要な代表ファイルを確認してから判断してください。
今後の調査では、この対応関係を使って
関連しそうなファイルを探してください。
すると、たとえば、
| 場所 | 役割 |
|---|---|
controller/ |
画面やAPIからの入口 |
service/ |
業務処理 |
repository/ |
DBアクセス |
resources/sql/ |
SQL |
config/ |
設定 |
test/ |
テスト |
のように、単なるファイル一覧へ意味が付きます。
この地図を最初に作っておくと、その後の調査の質が大きく変わります。
ログにあるクラス名が出てきたときに、そのファイルだけを見るのではなく、
「これはServiceだから、Repository側も確認したい」
「DBアクセスまで追うならSQLも必要そうだ」
と、関連する場所へ調査を広げられるようになります。
また、実務では実態と異なる名前がフォルダやファイルについていることもあります。
この罠を回避できます。
PowerShellで検索コマンドを作らせるときも同じです。
プロジェクト構成を知らないAIに、
関連ファイルを検索して
と頼むより、どこに何があるか分かっているAIへ頼んだ方が良いのは自明です。
まずファイル名の一覧を渡して、それをシステムの地図に変える。
ここまでできたら、次は個々のファイルを本当に必要なところまで読めているかを確認します。
5-3. 「ファイルがある」と「全文を読めた」は分けて考える
/mnt/data に実ファイルが存在しているからといって、AIがその内容をすべて取得できているとは限りません。
長いファイルでは、File Fetchなどのfetch系機能で取得した内容が途中までになることがあります。
実ファイルは作業机に残っていても、一度のfetchでAIが受け取った本文が全文とは限らないわけです。
10万行のログを渡して、先頭数千行だけ見た状態で、
「確認しました。原因はこれです」
と始められたら困ります。
私の周囲では、「Copilot/ChatGPTはダメだ、バカだ～」と感じていた原因が、実はこれだったケースがかなり多いです。
「fetchで見切れてない？ って返してみて」とアドバイスすると大体解決してます。
なので私は、
「全部読んで」ではなく、「全文を確認できたことを確かめて」
と先に規定しています。
全文確認が必要なファイルなら、
- 総行数を確認する
- 取得できた範囲を確認する
- 末尾まで到達したか確認する
- 一度で取得できなければ分割する
- 全体を確認できてから判断する
という流れにします。
wc -l /mnt/data/編集したいコード.java
tail -n 20 /mnt/data/編集したいコード.java
のような方法が使えるなら、これを使わせます。
大切なのは、
存在確認と読了確認を別の工程にすることです。
「ファイルがある」だけでは足りません。
「ファイルのサイズを知り、かつ必要な範囲を読めた」まで確認して、初めてそのファイルを判断材料として使わせます。
さあ、ここまでで、AIは「今持っている資料」については自力で扱えるようになりました。
次は、今の資料だけでは足りないときの話です。
5-4. 足りない資料はAIに決めさせる
調査を進めていると、当然、今ある資料だけでは判断できない場面が出てきます。
そこで人間が毎回、
「次はこのソースかな～」
「このログも必要かな～」
と考えていては、結局こちらが調査を指揮することになります。
認知負荷なんてものはない方が良いに決まっているので、ここもAIへ渡します。
現在の資料だけで判断できない場合は、
不足している情報を具体的に特定してください。
ローカルPCから取得できる場合は、
何を取得すれば判断できるのかまで決めてください。
たとえば、
- ログからクラス名が分かった → そのソースが必要！
- Serviceの処理が怪しい → RepositoryやSQLも確認したい！
- 画面仕様との不一致が疑われる → 画面設計書が必要！
- DBの値が原因かもしれない → DB検索結果が必要！
といった具合です。
5-2でプロジェクトの地図を作っているので、
「関連ファイルが必要です」
だけで終わらず、
「このディレクトリにある、この種類のファイルを確認したい」
まで具体化しやすくなります。
ここまでAIに決めさせたら、人間側の仕事は単純です。
AIが必要だと叫んだものを取りに行きます。
その取得作業も、なるべく人間に考えさせません。
5-5. PowerShellは資料収集用に生成させる
AIから直接見えないローカルPCの情報が必要になったら、取得用のPowerShellをAIに作らせます。
AIがコマンドを作る → 人間が実行する → 結果をファイルで渡す。
この3段階です。
たとえば、プロジェクト内から特定のクラスを探したいなら、
Get-ChildItem "C:\work\sample-app" -Recurse -File -Filter *.java |
Select-String -Pattern "TargetClass" |
Out-File ".\Powershellの検索結果.txt" -Encoding utf8
ログから特定のリクエストIDを追いたいなら、
Select-String `
-Path "C:\logs\*.log" `
-Pattern "request-id-12345" `
-Context 20,20 |
Out-File ".\Powershellの検索結果.txt" -Encoding utf8
のような形です。
ポイントは、結果を画面に出して終わらせないことです。
/mnt/dataに残せるよう、いつでも再利用できるよう、ファイルとして残します。
実務では、もっとまとめて取得するコマンドもよく作らせています。（M365 Copilot無料版では一度に渡せるファイルが三つまでと、謎すぎる最悪な仕様があるため）
たとえばAIが、
「このクラスの定義、使用箇所、周辺実装をまとめて確認したい」
と判断したなら、
- 対象ファイル一覧
- 対象ソース全文
- クラスやメソッドの検索結果
- ヒット箇所の前後
- 類似実装
- 調査日時
- 対象ディレクトリ
まで、一つのtxtへまとめるPowerShellを生成させます。
$root = "C:\work\sample-app"
$outFile = ".\Powershellの検索結果.txt"
$sourceFiles = Get-ChildItem $root -Recurse -File -Include *.java,*.dart
"===== 対象ファイル一覧 =====" | Set-Content $outFile -Encoding UTF8
$sourceFiles |
Select-Object FullName, Length, LastWriteTime |
Format-Table -AutoSize |
Out-String -Width 500 |
Add-Content $outFile -Encoding UTF8
"===== 対象文字列の検索 =====" | Add-Content $outFile -Encoding UTF8
$sourceFiles |
Select-String -Pattern "TargetClass|targetMethod|TARGET_CONST" -Context 20,40 |
Out-String -Width 700 |
Add-Content $outFile -Encoding UTF8
何を検索すれば判断できるかはAIに考えさせます。
私は生成されたコマンドをローカルPCで実行して、できたファイルをチャットへ戻すだけです。
そして、先ほど少し触れましたが、この検索結果は使い捨てにはしません。
5-6. 調査結果は作業机にためていく
この運用で特に効いているのがここです。
PowerShellで取得した検索結果やログの抽出結果は、その場でチャットで送って終わりにはしません。
ファイルとして /mnt/data の作業机へ追加します。
たとえば、最初は、
編集したいコード.java
だけだった作業机が、調査を進めるうちに、
project_tree.txt
編集したいコード.java
画面設計書.xlsx
詳細設計書.xlsx
PT仕様書.xlsx
Powershellの検索結果1.txt
Powershellの検索結果2.txt
Powershellの検索結果3.txt
最新動作確認ログ.txt
と増えていきます。
するとAIは、
- プロジェクト上ではどこに属する処理か
- 設計書でどう動くべきとされているか
- 現行コードではどう実装されているか
- 他の類似処理ではどうしているか
- 実際のログではどこを通ったか
を、同じ作業机の上で突き合わせられます。
作業机に調査結果が増えるほど、そのチャット内のAIは仕事をしやすくなります。
最初は何も知らなかったAIが、調査を進めるうちに「この案件の話が通じる担当者」になっていきます。
一度調べたことをファイルとして残しておけば、それ自体が次の調査材料になります。
調査するたびに、次の調査を楽にする。
この状態を作ります。
5-7. 巨大ログは全部読ませず、検索から入る
最後に、大量データだけは少し扱い方を変えます。
10万行のログを頭から順番に読ませても、効率が良くありません。
元ログを作業机へ置いたうえで、まず検索します。
grep -n "ERROR" /mnt/data/application.log
grep -n "NullPointerException" /mnt/data/application.log
grep -n "request-id-12345" /mnt/data/*.log
入口を見つけたら、
- エラー箇所を特定する
- 前後を見る
- IDを拾う
- 同じIDを別ログから探す
- クラス名・API名を特定する
- ソースへ移る
- 設計書と比較する
と進めます。
必要なら、その検索結果自体もファイルとして残します。
最終回答だけ残してしまうと、あとから、
「これ、何を根拠にそう判断したんだっけ？」
となります。
検索結果やログの抜粋も作業机に残しておけば、そのときAIが見ていた事実をもう一度たどれます。
エビデンスは、チームメンバーへの説明の際にも役立ちます。
私の実務用Copilotでは、このほかにも「どの版・どのDB・どの環境を見ているか」「設計上の正しい動作は何か」「確認済み事実と推測を分けられているか」「第三者が引き継げる記録になっているか」まで規定しています。
最初から全部入れる必要はありません。
AIが変な動きをしたら、その都度「次からそれをしないための手順」を足していくくらいで十分です。
ガンガンPDCAを回していきましょう！
ここまでで、AIに覚えさせたい調査手順は一通り揃いました！
ただし、これを毎回チャットへ貼っていたら面倒すぎて本末転倒です。
次章では、これらの規則をどこに保存して、普段の依頼を短くするかを整理します。
6. 作業規則は毎回書かない
ここまでの規則を、毎回チャットへ貼る必要はありません。
内容ごとに置き場所を分けます。
| 置き場所 | 向いている内容 |
|---|---|
| カスタム指示・親プロンプト | 常に守ってほしい調査手順 |
| メモリ | 長期間変わりにくい自分の環境・好み |
| プロジェクト内ファイル | 案件固有の構成・ビルド方法・既知の問題 |
| 毎回のチャット | 今回だけの依頼 |
たとえば、親プロンプトには、
- ファイル受領時の実在確認
-
/mnt/dataの一覧確認 - 全文確認の方法
- 不足資料の判断
- PowerShell生成の役割
- 事実と推測の分離
- 成果物の確認
を入れます。
プロジェクト固有の情報は、
AI_GUIDE.md
PROJECT_MAP.md
POWERSHELL_GUIDE.md
BUILD_GUIDE.md
KNOWN_ISSUES.md
のようなファイルにしておくと扱いやすいです。
もちろんこれもAIで作ります。
置き場所が決まったら、最後に共通部分をひとつの親プロンプトへまとめます。
以下は、そのまま叩き台にできる最小構成です。
7. 再現用の親プロンプト
ここまでの内容を、最低限の形にまとめると次のようになります。
# ファイルを使った調査の基本規則
プログラム、ログ、設計書、設定ファイルなどを使って回答する場合は、
あなたから直接参照できるファイル領域（具体的には /mnt/data など）を、調査用の作業机として扱ってください。
## 調査開始時
1. 現在参照できるファイルを実際に確認する。
2. 表示上の添付一覧や抜粋だけを根拠にしない。
3. 必要に応じて、ファイル名・サイズ・更新日時を確認する。
4. 今回の調査に使うファイルと、その確認状態を整理する。
5. 存在を確認できないファイルを、存在する前提で扱わない。
## プロジェクト構造の把握
6. コード調査では、可能な限り最初にプロジェクト全体のディレクトリ構造を確認する。
7. project_tree.txt などが存在する場合は、それを確認する。
8. プロジェクト構造が不明な場合は、人間がローカルPCで実行できる tree コマンドやPowerShellコマンドを生成し、構造をファイルとして取得するよう依頼する。
9. ディレクトリ名やファイル名だけを見るのではなく、主要なディレクトリ・主要ファイルが何を担当しているか整理する。
10. 名前だけでは役割を判断できない場合は、代表的なファイルを確認して役割を特定する。
11. 一度整理したプロジェクト構造と役割の対応関係は、その後の関連ファイル探索に利用する。
## ファイル確認
12. ファイルが存在することと、その内容を必要な範囲まで確認できたことを分けて扱う。
13. 全文確認が必要なファイルは、必要に応じて総行数・取得範囲・末尾を確認する。
14. File Fetchなどで一度に全文を取得できない場合は、分割して確認する。
15. 未確認の内容を確認済みとして扱わない。
16. 全文確認が不要な巨大ファイルは、目的に応じて検索を使う。
## 調査
17. エラー、ID、クラス名、関数名、設定値などを手掛かりに関連資料を探す。
18. 現在把握しているプロジェクト構造を使い、直接の対象ファイルだけでなく、関連する処理・設定・SQL・設計書などまで調査範囲を広げる。
19. 情報が不足している場合は、推測する前に不足している資料や情報を具体的に特定する。
20. 次に何を調べれば判断材料が増えるかを考え、必要な追加調査を提案する。
## ローカルPCからの資料取得
21. AIから直接参照できない資料が必要な場合は、何を取得すればよいか具体的に決める。
22. Windows上で取得可能な場合は、人間がローカルPCで実行するPowerShellコマンドを生成する。
23. PowerShellでは、必要なファイルの収集・文字列検索・前後行の取得・関連ファイル一覧の取得など、今回の判断に必要な情報をまとめて取得できる形を優先する。
24. コマンドの実行結果は、原則として画面表示だけで終わらせず、txtなどのファイルへ保存する。
25. 人間が収集したファイルは、AIから参照できる作業机へ追加する前提で考える。
26. ファイルが追加されたら、作業机を再確認し、新しく追加された資料を把握する。
## 調査結果の蓄積
27. PowerShellの検索結果、ログ抽出結果、比較結果、DB確認結果などは、可能な限りファイルとして残す。
28. 新しい調査結果を受領したら、既存の設計書・ソース・過去の調査結果と関連付けて扱う。
29. 一度確認した内容を、その場限りのチャット上の情報だけで終わらせない。
30. 調査が進むたびに、作業机の中だけで次の判断に必要な材料が揃っていく状態を目指す。
31. 過去の調査結果も次の調査材料として利用し、同じ確認を不要に繰り返さない。
## 巨大ログ・大量データ
32. 巨大ログは、最初から全文を順番に読むことを前提にしない。
33. ERROR、WARN、例外名、日時、リクエストID、トランザクションID、クラス名などを手掛かりに検索する。
34. 検索で入口を見つけたら、その前後を確認し、そこから得たIDやクラス名を使って追加検索する。
35. 必要に応じて、検索結果そのものもファイルとして保存し、作業机へ追加する。
## 成果物
36. 調査結果と必要な証跡は、後から再確認できる形で残す。
37. ファイルやZIPを生成した場合は、生成成功だけで終わらせず、実在・中身・必要ファイルの有無を確認する。
38. 確認済みの事実と推測を分ける。
39. 判断できない場合は、無理に結論を出さず、未判定または保留として扱う。
40. 未判定または保留の場合は、判断するために追加で必要な情報を具体的に示す。
M365 Copilotには親プロンプトの概念が基本的にはないので、全部メモリーに覚えさせてください。
それで充分です。
ここまでで再現方法は終わりです。お疲れ様でした！
次の章では、この運用でClaude CodeやCodexとの差が実際どこまで縮まるのかを整理します。
8. 専用エージェントとの差はどこまで埋まるか
Claude CodeやCodexのようなコーディングエージェントは、プロジェクトへ直接アクセスして、検索・編集・コマンド実行・テストまで連続して進められますよね。
これは当然非常に便利で、私も現場に入る際にエージェント系のAIが使えないと聞いたときには「これはどうしたものかな～」と頭を悩ませたものです。
これだからAIゆとり世代は……。（※この人は冗談を言っています）
しかし今回の方法でも、/mnt/data の中に必要な資料と調査結果が揃った後は、かなり近い使用感になります。
3章で触れた通り、作業机の中はAI自身が直接操作できます。
ここまでの作業規則を入れておけば、その資料を使って探索・検索・比較・成果物作成まで継続できます。
チャット系のAIとAIエージェントの大きな差は、ローカルPCへ直接アクセスできるかどうかです。
チャット系のAIも、自身の作業領域の中ではコーディングエージェントと同等の働きが出来ます。
（実際はサブエージェントなど、他にもいろいろ便利な機能が沢山あるのでそうでもないんですが、一旦そうさせてください。少なくとも、ファイルを探す・読む・検索する・比較する・成果物を作る、という単一フローではかなり近い動きができます）
であるなら、エージェントが持っている「自分で情報を取りに行く力」を、AIの判断 + 人間のファイル搬送で補おうぜ！ というのが今回のお話でした。
完全自動ではありませんが、このレベルの半自動でも実務ではかなり快適です。
ありえないレベルのスピードで知識を収集して結果を出せるので、現場での評価もうなぎのぼりです。わー、なろう系みたいだあ。
というのも、半自動なのは一見して妥協に見えるんですが、これは検索結果をある程度目で追いながら作業させられるということなので、自然と人間側に知見がたまっていくメリットがあります。
AIに全任せしているつもりが、いつの間にか自分自身がプロジェクトの生き字引になっているわけですね。
そうすると、AIの出力がおかしくなった際にも、ビビっときて「なんかおかしくね」と気づけるようになりますし、他のチームメンバーの質問にポンと答えられるようになります。
自分自身が他のチームメンバーにとってのチャッピーになります。いつの間にかなってます。
これは、全部勝手にやってくれてしまうエージェント系のAIにはない利点だと思っています。
実際言いにくいことなんですが、Claude Codeでやっている個人開発のプロジェクトより、現場のプロジェクトの方が私詳しいんですよねー……。
ちょっぴり複雑！
9. まとめ
ここまでの流れをまとめます。
-
/mnt/dataをAIの作業机として扱う - 作業机にある資料はAI自身に確認・検索・比較させる
- 足りない資料はAIに判断させ、取得用PowerShellもAIに作らせる
- 人間はコマンドを実行し、結果をファイルとして作業机へ戻す
- 調査結果を作業机へ蓄積し、次の判断材料として使う
- File Fetchは全文取得とは限らないため、行数や末尾まで確認させる
- この一連の手順は親プロンプトやメモリへ保存し、普段の依頼は短くサボる
私が欲しかったのは、
ちゃんと資料を見て、足りなければ取りに行く方法を考えて、確認した事実を残したうえで仕事を進めてくれるAI
でした。
そのために必要だったのが、今回の作業規則です。
こうして最初に仕事の進め方を教えておけば、普段は雑～にテキト～に頼めます。
最高ですね～！！
毎回きれいなプロンプトを書く必要はありませんし、そんな事はしたくありません。
エンジニアの本音はいつだって、「可能なだけサボりたい」です。
ここには忠実に行きましょう。要件定義、ダイジ。
AIに何が欲しいかを伝えるより先に、どうやってそれを手に入れるかを規定する。そしたら後は雑に頼む。
冒頭で述べたこの考え方を、大事にしてみてください。
最後に補足として～。
AIの言う事や出力は鵜呑みにせず、ちゃんと自分の目で出典元のデータと見比べる、動作確認をする、メンバーと共有して確認する──こういった石橋を叩く類の努力は、億劫でも決してサボらないようにしましょう！！
特に、実際の現場では参照した資料そのものがウソをついていることも多いです。（※現場未経験者の方はウソやろと思うかもですが、本当に多いです）
この辺りは人間同士のコミュニケーションで補うしかない部分なので、「AIで調べるから教えてもらわなくていいや」とするのはちょびっと危険だったりします。
まあその辺りの不整合や「なんかこの資料おかしくね」というのも、AI側で検知することができるので使い方次第なんですけどね……。
あくまでも、超便利な検索+生成ツール。
あくまでも、時短、効率化。
あくまでも、主体は人間！！
今後の進化でAIがどうなっていくかは分かりませんが、きっちり線引きしてやるのが今のところはベターだなぁというのが私の感想です。
AIのスゴさに呑まれて損をしないように、気を付けていきましょう！
ツールは得するために使うものですからね～～。
パレットリンクでは、日々のつながりや学びを大切にしながら、さまざまなお役立ち記事をお届けしています。よろしければ、ぜひ「Organization」のページもご覧ください。
また、私たちと一緒に未来をつくっていく仲間も募集中です。ご興味をお持ちの方は、ぜひお気軽にお問い合わせください。一緒に新しいご縁が生まれることを楽しみにしています。