道具 × AI で作業環境を整える

Claude Codeとは何か｜任せる前に知っておきたい、実際に起きた3つの事故

Claude Codeとは何か｜任せる前に知っておきたい、実際に起きた3つの事故
運営 在宅ワーク最適化ラボ公開 2026-08-17ノウハウ

ChatGPTにファイルの中身を貼り付けて、返ってきたものをまた貼り戻す——この往復を無くすのが Claude Code です。ターミナル（コマンドを打つ黒い画面）で動き、AIが自分でファイルを開いて読み、書き換え、コマンドを実行します。

ただ、この記事で本当に伝えたいのは「便利です」という話ではありません。運営者がこのサイトを作る過程で実際に起こした3つの事故です。ファイルに手が届くということは、間違いも手が届くということでした。

料金・提供形態・利用条件は変わるため、最新の情報は必ず公式で確認してください。

結論：違いは「ファイルに手が届くかどうか」

📌 先に結論 チャット型のAIは会話の中でしか作業できません。Claude Codeは手元のフォルダを直接読み書きし、コマンドを実行して結果まで見られます。この一点で扱える作業の大きさが変わる代わりに、間違いもファイルに書き込まれます。

チャットに貼り付ける運用Claude Code
対象会話に貼った分だけフォルダの中のファイルそのもの
複数ファイル全部貼る必要がある自分で探して読む
結果の反映手でコピペして戻すそのまま書き換わる
実行・確認できないコマンドを実行して結果を見られる
失敗したとき貼り戻さなければ無害すでに書き換わっている

いちばん効くのは4行目、いちばん怖いのは5行目です。ここから、その5行目の話をします。

事故①：「重大バグ」の犯人が、自分のブラウザの広告ブロッカーだった

このサイトのアクセス解析（GA4）で、クリック計測のイベントが記録されていないように見えました。ブラウザの開発者ツールで見ると、Googleのタグを読み込む googletagmanager.com/gtag/js が 503（サーバーエラー）を返しています。

ここでAIと運営者が出した結論はこうでした。

サイト側の障害。配信基盤のプロキシがGoogleタグを壊している。

そしてこれを、プロジェクトの指示ファイルに**「🔴 未解決の重大バグ・最優先」として書き込みました。**

実際は違いました。あとで測り直すと、

  • サーバーは 5回連続で200（正常）を返していた
  • 別のブラウザでは普通に読み込めた
  • 原因は、そのブラウザに入れていた広告ブロッカーがGoogleタグを遮断していただけ

さらに途中で「CSSの overflow-x: clip がスクロール計測を壊している」という別の誤診も挟んでいます。これも実際は、検証用に window.scrollTo でプログラム的にスクロールさせた操作が効かなかっただけで、実ユーザーのスクロールは正常でした。

⚠ ここから学んだこと ① 1つのブラウザだけ見て「サイトのバグ」と断定しない ② 計測の検証は拡張機能の無い環境で行う ③ 「503を観測した」までが事実で、「プロキシが原因」は憶測だった

③が本質です。AIは観測と推測を同じ調子で書きます。「〜が原因です」と書かれていたら、それが実際に確かめられた事実なのか、辻褄が合うだけの仮説なのかを聞き直してください。

そして計測系で最も多い間違いは、「発火したこと」は見ても「届いたこと」を見ていないことです。正しい確認は2段階でした。

手順1：そもそもタグ本体が読み込めているか

typeof window.google_tag_manager === 'object'
  && Object.keys(window.google_tag_manager).includes('G-XXXXXXXXXX')

false ならタグが遮断されています。この時点でイベントは1件も届きません。

手順2：実際に送信されているかを捕まえる

window.__full = [];
const of = window.fetch;
window.fetch = function (u) {
  const s = String(u);
  if (s.includes('/g/collect')) window.__full.push(s);
  return of.apply(this, arguments);
};
const ob = navigator.sendBeacon.bind(navigator);
navigator.sendBeacon = function (u, d) {
  const s = String(u);
  if (s.includes('/g/collect')) window.__full.push(s);
  return ob(u, d);
};
// → 計測したいボタンをクリックして、数秒待ってから
window.__full.map((u) =>
  Object.fromEntries(
    [...new URLSearchParams(u.split('?')[1])].filter(
      ([k]) => k === 'en' || k.startsWith('ep')
    )
  )
);

fetch と sendBeacon の両方を包むのが要点です（GA4はどちらでも送ります）。まとめて送信されるので、クリック直後は0件のことがあります。数秒待ってください。

これで実際に送信を確認できたので、「重大バグ」は取り下げになりました。AIの断定を1回信じたせいで、無いバグを最優先タスクとして数時間追いかけたわけです。

事故②：エージェントがリストの122件を「移動」ではなく「削除」した

別の作業で、Googleマップの保存済みリストを地域別に振り分けさせていたときの話です。前半は問題なく進んでいましたが、後半の速いバッチが「移動」ではなく×ボタンでの削除だけを実行しました。

結果、約122件が消失しました。

最悪だったのは復元できなかったことです。エージェントは**「◯件処理しました」という件数だけを報告し、店名を記録していませんでした。** 作業ログから約60件は名前を拾えましたが、残り約50件は何が入っていたのかも分かりません。

ここから作った再発防止ルールは3つです。

ルールなぜ
「削除」ではなく 「移動先に追加 → 保存を確認 → 元のチェックを外す」 の順序を明示する順序を書かないと、結果が同じに見える最短手順を選ぶ
処理した各項目の名前を必ず報告に含めさせる（件数だけの報告を禁止）名前の記録が唯一の復元手段
検証は移動先の件数が増えたかで見る元の件数が減っただけでは、移動と削除を区別できない

3つ目が地味に効きます。「元のリストが122件減りました」は、成功の報告としても失敗の報告としても成立してしまいます。どちらとも読める指標で確認しない——これは他の作業でもそのまま使える教訓でした。

なお、Googleマップのリストに個別のゴミ箱や取り消しはありません。取り消せない操作を伴う作業を任せるときは、この手順の明示が必須だと考えています。

事故③：並列で速くしようとして、逆に遅くなった

「サブエージェント（別枠で動く子AI）を並列で走らせれば速い」と思って、実際にやってみた結果です。

  • 2026年6月9日〜20日の間に、利用量の上限（セッション制限）に6回以上到達
  • 単一のやり取りで 55万〜58万トークン（キャッシュ読み込み分）まで膨らんだ記録あり
  • 上限が近づくとツールの出力が壊れ、コミットが失敗するようになる

そして見落としやすいのがこれです。

⚠ 上限はアカウント全体で合算される 別プロジェクトで走らせているセッションが、いま作業している枠を食います。「このプロジェクトではそんなに使っていないのに」は通用しません。

ブラウザ操作を伴う作業では、さらにはっきりした数字が出ました。1エージェントで184回のツール呼び出し・約31万トークン・約42分かけて、処理できたのは2件。 並列を2エージェントに増やしたら、相手側から HTTP 503（レート制限）が返り始め、動作そのものが不安定になりました。

結論は、並列化は逆効果で、単独エージェントの連続バッチが最速。ブラウザのタブグループも、安定して使えたのは実質2タブまででした。

現在の運用は次のとおりです。

  • サブエージェントは4体以下のバッチで回す
  • 上限が近いときは、親が1ツールずつ淡々と処理する
  • 「コミットしました」と報告されたら git log で実体を確認する（壊れた出力でも報告文だけは成立するため）

Windowsで最初に踏む2つの地雷

Windows（PowerShell）で使うなら、この2つは先に知っておくと丸1日得します。

地雷1：git commit -m "..." が壊れる

PowerShellの引用符の扱いで、コミットメッセージが意図しない形に壊れます。メッセージをファイル経由で渡すのが確実です。

git commit -F .git/COMMIT_MSG.txt

（あらかじめ .git/COMMIT_MSG.txt にメッセージを書いてから実行します）

日本語や記号を含む複数行メッセージでは、これを標準手順にしています。

地雷2：日本語ファイルが文字化けする

PowerShell 5.1 で、UTF-8の日本語ファイルを Get-Content して Set-Content で書き戻すと文字化けします（読み込みの既定がANSIのため）。実際に文字化けしたままコミットしてしまい、全文を復元する羽目になりました。

対策はシンプルです。

📌 日本語ファイルはシェル経由で書き戻さない 編集は Claude Code の Edit / Write（ファイル編集の機能）で行う。Get-Content → Set-Content のパイプで日本語ファイルを通さない。

なお、すでに文字化けした名前のファイルを操作するときは、-Path ではなく -LiteralPath を使ってください。ワイルドカードとして解釈されて別のファイルに当たる事故を防げます。

向いている作業・向いていない作業

事故の話が続きましたが、当然ながら効く場面のほうが多いです。

向いている

  • 複数ファイルにまたがる書き換え（どこにあるか把握していなくても頼める）
  • 「何がどうなっているか分からない」の解明（人が読む前に地図を作らせる）
  • 合否がはっきり返る作業（テスト・ビルド・検証スクリプト。AIが自分で結果を見て直せる）

向いていない

  • 何を作るべきかが決まっていないとき。 方針の決定は人間の仕事です
  • 手元のファイル以外に答えがある作業
  • 一発勝負で失敗できない操作（削除・送信・公開・課金）

3つ目は、事故②がそのまま実例です。取り消せない操作は、手順を明示するか、人が実行する——ここは最初に線を引いておくべきでした。

プログラマーでなくても意味がある使い方

「コーディング支援」と説明されるので誤解されますが、扱っているのは結局テキストファイルです。

場面頼み方の例
設定ファイルの確認「この設定ファイルの項目を説明して。危なそうな設定があれば指摘して」
CSVの整形「日付表記がバラバラなので YYYY-MM-DD にそろえて。まず変更案だけ見せて」
大量ファイルのリネーム「写真を『撮影日_連番』に変えて。変更前後の一覧を全件出してから実行して」
手元資料の横断確認「このフォルダの議事録を全部読んで、未完了のタスクだけ抜き出して」

最後の行は、チャットに貼り付ける運用では現実的に無理です。数十ファイルを人が貼るわけにはいきません。

3行目の太字部分は、事故②の教訓をそのまま適用したものです。件数ではなく名前を出させる。

使う前に決めておく3つ

⚠ 最初に決めておくべき3つ ① 変更を元に戻せる状態にしておく（バージョン管理・バックアップ） ② 機密情報を含むフォルダで使わない ③ 止める操作（送信・削除・公開・課金）を先に伝えておく

②は勤務先のルールが最優先です。会社の資料を扱うなら、AI利用の社内規定を先に確認してください。

なお、機能を追加する「スキル」を入れるときは、これに1つ足してください。スキルの導入は、他人が書いたコードと指示文を、自分のファイルが全部見える場所で動かすことです。実際に静的解析にかけたら CRITICAL 判定が出て、調べたら全件誤検知だった——という顛末はAIスキルは他人のコードを自分のPCで動かすことにまとめました。

③は「お願い」ではなく設定で止められます。読み取りと検査は無制限に許可して摩擦をゼロにし、戻せないものだけ拒否する——その具体的な書き方はCLAUDE.mdの書き方にまとめました。

まとめ

Claude Codeは「賢いチャット」ではなく、手元のファイルに手が届くAIです。だから貼り付け運用では回らなかった規模の作業が回ります。

同時に、この記事で挙げた3つの事故はすべて「AIが嘘をついた」話ではなく、確認の設計が甘かった話です。

  1. 観測と推測を区別させる（事故①）
  2. 件数ではなく名前を報告させる（事故②）
  3. 並列で速くなると思わない。報告を git log で裏取りする（事故③）

指示の出し方そのものは、チャット型のAIと同じ考え方が使えます → AIへの指示（プロンプト）の書き方

次に読むなら、この2本が実務に直結します。

チャット型AIでの業務効率化はChatGPTで在宅ワークを効率化する使い方にまとめています。