AIにCSVの整理を頼んだら、それらしいコードと説明がすぐ返ってきた。動いているように見える。でも、そのAIが本当に私のファイルを開いたのかは、どうやって確かめればいいんだろう。
私の環境では、開いていませんでした。列名を想像で書いていたのです。ただ、私の環境で再発を減らせた書き方は見つかりました。依頼文を3つのブロックに割る、それだけです。新しいツールは使っていません。
⚠️ この記事の情報は2026年8月時点のものです。筆者のシステムは相場を観測・研究するためのもので、自動発注はしません（read-only＝読み取り専用）。実際のお金での発注はしていません（仮想発注のみ・実発注なし）。内容は随時更新します。
この記事で分かること
2026年8月8日、私の手元でAIが書いた検査ルールは、CSVの中から as_of、dataset、age_days という3つの列を探していました。どれも実在しません。修正コミットの説明文には、こうありました。そのファイルを一度も開いていなかった、と。
結論を先に置きます。実ファイルを扱わせるときの依頼文は、「目的」「触らない範囲」「確認手順」の3ブロックに割って書く。この形にしたところ、私の環境では、AIが想像で埋めた箇所が返答の中で浮き上がりました（効果を数値で測ったわけではありません）。
プロンプトの一般的な書き方は別記事にまとめてあります。この記事は、そこから範囲を絞って「手元の実ファイルを触らせるとき」だけを扱います。
【早見表】依頼文の3ブロックと書くこと
| ブロック | 依頼文に書くこと | 抜けると起きたこと（筆者の環境） |
|---|---|---|
| ① 目的 | 何を判定したいのか。ファイルの1行目（列名）をそのまま貼る。生成元も1行添える | 実在しない列名を探すコードが書かれた |
| ② 触らない範囲 | 合格条件を番号つきで列挙し「これ以外の条件を足すな」。書き込み禁止も明記 | 頼んでいない5つ目の合格条件を勝手に足していた |
| ③ 確認手順 | 「確認済み／未確認／判断できない」を分けて報告。完了条件を先に決めておく | 眺めただけの箇所を「検証済み」と名乗っていた |
手順1 実ファイルの1行目（列名）をそのまま貼る
私の環境では、AIがファイルの中身を推測で埋めることがありました。だから困る。それらしい列名を出されると、確認する気が起きないからです。
貼らないと何が起きるか
私の環境で実際に使われていたCSVの列は、tier / last_run_id / last_collected_at / status / row_count / note の6つでした。AIが探していた3つとは1つもかぶっていません。
さらに厄介だったのが文字コードです。このCSVはBOM付きのUTF-8（先頭に見えない印がついた保存形式）で書かれていて、その印を外さずに読むと1列目の名前が壊れます。すると「列の並びが違う」という誤判定になる作りにしてあります。だから読み込み方を utf-8-sig に合わせました。これは公式リファレンスの話ではなく、自分の環境で、生成元がその形式で書いていることを確認して合わせた記録です。
もうひとつ。AIは「経過日数」の列があるつもりで設計していましたが、実際の台帳にそんな列はありません。最終収集時刻と基準時刻の差を自分で計算するしかない。列名を1行貼るだけで避けられた設計ミスです。
コツ：列名だけでよい・中身の値は貼らない
貼るのは1行目だけ。2行目以降の実データは貼らないでください。取引先名、社員名、金額——業務データの中身をチャット欄に流す必要は、この目的にはありません。
もう1行だけ足すと効きます。そのファイルを誰が作っているかです。私の場合、修正の過程で「この台帳を書いているのは共通モジュールで、呼び出し箇所は20か所ある」と分かりました。読む側の都合で列名を変えたら、20か所が壊れる。この情報があるだけで、AIの提案は「読み方を直す」方向に寄ります。
手順2 条件を列挙し「それ以外を足すな」と書く
同じ修正コミットには、2つ目の是正が書かれていました。こちらのほうが見つけにくい。
厳しくするのも逸脱＝頼んでいない合格条件を勝手に足していた例
仕様書に書いてあった合格条件は4つでした。鮮度が範囲内であること、欠損がないこと、重複がないこと、時刻が記録されていること。ところがAIは5つ目として「statusの値がokであること」を追加していたのです。
一見、良かれと思ってのことに見えます。でも仕様から外れています。緩めるのと同じくらい、厳しくするのも逸脱——コミットの説明文はそう整理していました。修正後、statusは合否を決めない「観測」の欄へ移されます。結果、ある収集元のstatusが空欄でも判定は合格になり、空欄だという事実は注記として残る形になりました。
「念のため」で条件を1つ足した成果物は、あなたの仕様ではありません。だから依頼文には、こう書く。
- 合格条件は次の◯つ（自分の条件の数を書く）。番号をつけて全部書く
- これ以外の条件を足さない。緩めるのも厳しくするのも同じく禁止
- 気づいた点があれば、合否とは別枠に「気づき」として書く
- 元ファイルは読むだけ。書き込み・上書き・削除はしない
手順3 「確認済み」と「未確認」を分けて報告させる
3つ目のブロックが、私にはいちばん手応えがありました（効き目を数字で比べたわけではありません）。
同じ修正で、別の検査項目は実データに対してUNKNOWN（判断できない）を返しました。台帳の270行が古い形式で、比較に必要な項目を持っていなかったからです。ここでUNKNOWNを合格に書き換えなかったのが分かれ目でした（「UNKNOWNをPASSへ変換していない」と明記されるのは翌日のコミットです）。同じ8月8日のコミットには、逆向きの自制も書かれています。別の検査項目が合格と測れても、それを隠せば手前の関門を通せる場面で、隠さなかった——「測定結果を隠してゲートを通すのは、通らないことより悪い」。弱く出た結果を強く言わないことと、都合よく隠さないこと。両方向に同じ原則が要ります。
静的に眺めただけで「検証済み」と名乗っていた宣言を、仮定へ格下げした例
翌日（8月9日）のコミットは、さらに一段深いところを直していました。AIが自分の登録内容につけていた「時点整合を検証済み（PIT_VERIFIED）」というラベルを、「仮定（PIT_ASSUMED）」へ自分で下げたのです。
理由が明快でした。実施したのはコードを静的に追う作業であって、実データを動かして時点整合（未来の情報を先読みしていないか）を確かめてはいない。だから「検証済み」は証拠より強い主張になる、と。
同じコミットには、まだ確定できていないことも並記されていました。読み取り専用での再実測では4段すべてが合格になった一方、別の判定は「呼び出しの形が自分の側で誤っていた。判定結果ではないので、遮断されていると読んではならない」と明記されている。未実施の工程があるので満点は主張しない、とも。
この「確認済み／未確認／判断できない」の3分割を、こちらから先に指定しておく。それだけで、私の場合は報告文の中の曖昧な箇所が自分から名乗り出てきました。
コピペで使える依頼文テンプレ
3ブロックをそのまま文章にすると、こうなります（③を「報告の書き分け」として2行に割っています）。角かっこの中を自分の状況に置き換えてください。
- 【目的】 ［ファイル名］について［やりたいこと］をしたい。このファイルの1行目（列名）は次のとおり： ［列名をそのまま貼る］。このファイルは［生成元・作っている仕組み］が書き出している。
- 【触らない範囲】 判定に使う条件は次の［N］つだけ： ①［条件］ ②［条件］ ③［条件］。これ以外の条件を足さない（緩めるのも厳しくするのも禁止）。元ファイルは読むだけで、書き込み・上書き・削除をしない。列名を勝手に変えない。
- 【確認手順】 作業が終わったら、次の3つに分けて報告する： (a) 実際に開いて確かめたこと (b) 未確認のまま残したこと (c) 材料が足りず判断できないこと。判断できないものを「合格」に書き換えない。列名を推測で補った箇所があれば、その旨を明示する。
- 【報告の書き分け】 合否と、気づいた点は別の欄に書く。条件に含まれない気づきは「観測」として残し、合否には反映しない。
長いと感じるかもしれません。ただ、この4行を書く時間より、想像で書かれた成果物を直す時間のほうが長い。少なくとも私はそうでした。
実録：AIが一度も開いていないファイルの仕様を書いていた日の時系列
気づいたきっかけ
8月8日の朝、AIは検査ルールを書き上げました。それらしい列名が並んでいる。おかしいと思ったのは、実データに当てて動かしたときです。朝の記録に残っているのは「どの検査項目も合格しない。検査ルールが読むはずの台帳が見つからない」という結果でした。
ところが実ファイルを探して開いてみると、台帳はちゃんとあり、探している列が1つも存在しませんでした。しかもその台帳は、当日も更新されていて14件分の行が入っている。ちゃんとそこにあったのです。誰も開かなかっただけで。
詰まった箇所と回避策
直すときに気をつけた点が2つあります。1つ目は文字コードです。この台帳を書いている側はBOM付き（utf-8-sig）で保存していたので、読む側も同じ読み方に合わせました。合わせないと1列目の名前が壊れ、「列の並びが違う」と誤判定される作りだからです（この誤判定は実際には踏んでおらず、生成元の書き方を先に読んで避けました）。2つ目は「列名が変わればまた同じことが起きるのでは」という不安です。
後者は、テストで列の並びを固定して解決しました。生成元のモジュールから列名の一覧を読み込み、読む側と一致しているかを機械が確かめる。ずれたら落ちます。Excelで言えば、参照先のヘッダーが変わったら気づける仕掛けです。
ちなみにこの一連の作業は、すべて読み取り専用で行っています。相場データを観測・研究するための仕組みであって、自動発注はしません。実際のお金での発注もしていません（仮想発注のみ・実発注なし）。
よくある失敗（テンプレを使っても防げないこと）
- 列名を貼っても、ファイルが複数あると取り違える。 似た名前のフォルダが2つあると、どちらを見たのか報告に書かれないことがある。私は依頼文に「どのパスを開いたか報告に書く」を足しましたが、効いたかどうかは数値では測っていません
- 「確認済み」の定義がずれる。 眺めた＝確認済み、と数えられることがある。実際に動かしたのか、コードを読んだだけなのかを分けて書かせる
- 条件を足すなと書いても、報告の文面で足される。 判定ロジックは正しいのに、まとめ文だけ強い言い方になっている。合否欄と気づき欄を分けるのはこのためです
- テンプレ自体が効いたかどうかは、まだ測れていない。 何割減ったといった数字は出せません。私の環境で「同じ種類の間違いに気づけた」という記録だけです
それと、これはAI全般の性質の話ではありません。私の環境で、この日、この頼み方をしたときにこうなった、という1件の記録です。
非エンジニアが得た教訓
- AIの成果物を疑う前に、依頼文に実ファイルの1行目が入っていたかを見る
- 条件を厳しくする方向の勝手な追加も、立派な仕様違反。合格条件は数を数えて渡す
- 「判断できない」を報告に残せる枠を先に作っておくと、合格に化けなくなる
- チャットに貼るのは列名まで。中身のデータは貼らない
- 完了条件を先に決めておくと、確認作業が「読む」から「照合する」に変わる
まとめと次に読む
AIが動いているように見えるとき、動いているのは文章の生成だけかもしれない。それを見抜く道具が、目的・触らない範囲・確認手順の3ブロックです。
今日いちばん短く始めるなら、次にCSVの処理を頼むとき、依頼文の冒頭に1行目をコピペするところから。それだけでも、私は返ってきた答えの読み方が変わりました。
関連記事
- Claude Codeへの指示文の書き方｜実ファイルに限らない、指示文の基本の型
- AIが作った数式・計算をどう検算するか｜出てきた成果物を確かめる側の手順
- マーケットスピード2 RSSの使い方｜Excelに実データを取り込む側の入門（観測用・read-only）
無料テンプレート配布のお知らせ
Claude Codeを安全・便利に使うための設定テンプレート（CLAUDE.md）を無料配布しています。メールアドレスをご登録いただくと、すぐにダウンロードリンクをお送りします。
免責事項
本記事は執筆時点（2026年8月）の情報に基づく、筆者個人の体験の記録です。記事中の自動売買システムに関する記述は、特定の投資手法や自動売買の利用を推奨するものではありません。投資には元本割れのリスクがあり、最終的な判断はご自身の責任で行ってください。また、本記事ではセキュリティに関わる話題に触れていますが、悪用防止の観点から、具体的な脆弱性や攻撃手法の詳細は記載していません。AIツールの仕様は予告なく変更される場合があります。最新情報は各公式ドキュメントをご確認ください。本記事の内容を用いて生じたいかなる損害についても、筆者は責任を負いかねます。
コメント