Claude Code に仕事を譲った日——残ったのは「判断」と「責任」だった

はじめに

私はもともとIS（インサイドセールス）、いわゆる営業サイドの人間だった。

コードは書けない。SQLも知らない。ターミナルを開いたこともなかった。そんな自分が、ある日開発部のCRE（Customer Reliability Engineering）チームに異動した。

CREの仕事は、お客様からの技術的な問い合わせを調査して回答すること。「承認フローが変わってしまった」「エクスポートが終わらない」「メールが届かない」——毎日そういった問い合わせがJiraに積まれていく。

調査には、本番DBへのクエリ実行、Rails/Reactのコードリーディング、ログの解析が必要になる。正直に言うと、最初は「自分にできるのか」という不安しかなかった。

でも今、私のPCでは毎時0分にClaude Codeが自動で起動し、Jiraから新しいチケットを拾い、コードとDBを調査し、回答ドラフトまで作ってSlackで通知してくれる。

この記事は、「Claude Codeをどう使うか」という話ではない。

調査業務を全自動化するまでの道のりと、その過程で見えてきた"AIには置き換えられない人間の価値" について書きたい。

1. CREという仕事と、最初の壁

CREに来て最初にぶつかった壁は、「調査の型がない」ことだった。

お客様から問い合わせが来る。Jiraチケットを開く。問い合わせ内容を読む。

……で、何をすればいい？

先輩に聞けば「まず企業IDを特定して、関連テーブルを見て……」と教えてもらえる。でも翌日、別の種類の問い合わせが来ると、また一からわからない。

承認フローの問い合わせなら変更履歴テーブルを見る。タイムスタンプの問題ならファイルストレージのステータスを見る。エクスポートのスタックならジョブ管理テーブルを見る。それぞれの調査にはそれぞれの「お作法」がある。

全部を頭に入れておくのは無理だった。特に、右も左も分からない自分にとっては。

ただ、チケットを何十件とこなすうちに気づいたことがある。最初はバラバラに見えた調査にも、大別すればパターンがあるということだ。見るテーブル、確認するログ、チェックするファイル——問い合わせの種類ごとに、ある程度の「お作法」は固まってくる。

問題は、それが先輩の頭の中や自分の記憶にしかなく、Notionにも断片的にしか残っていなかったことだ。

2. 「調査の型」を相棒に教え込む

だったら、そのパターンを全部書き出して、Claude Codeに覚えさせればいい。

最初はただの便利なAIアシスタントとして使っていた。「このテーブルの構造を教えて」「このエラーは何？」——一問一答のやり取り。

転機になったのは、同じ種類の問い合わせが2回目に来たときだった。

「これ、前にも調べたのに、また一から聞いてる……」

そこからSkillsの構築が始まった。

Skillsというのは、Claude Codeに特定のタスクの手順を教え込む仕組みだ。Markdownファイルに調査手順を書いておくと、Claude Codeがそれに従って自律的に調査を進めてくれる。

たとえば、「書類へのタイムスタンプが付与されない」という問い合わせに対応するSkillには、こんなことが書いてある。

タイムスタンプ調査スキル（抜粋・一部マスク）

主な失敗原因:

1. PDFにパスワードロックがかかっている（開く時 / 編集時の2種類あり）
2. 別ベンダーのタイムスタンプや電子署名が既に付与されている
3. PDF生成アプリケーションとの互換性問題（特定規格に非準拠、PDFバージョンが古い等）

調査手順:

1. ユーザー・企業を特定する
2. 対象ファイルのステータスを確認する（ステータス値で失敗原因を切り分け）
3. 同じ企業・同じ発行元で成功しているファイルを探し、失敗ファイルと比較する（セキュリティ設定、PDF生成元アプリ、PDFバージョン、既存の署名有無）
4. ログ基盤でファイルのIDをキーに検索し、エラーの詳細を特定する

お客様への対応パターン:

• パスワードロック / 互換性問題 → ブラウザで開いて「PDFとして再保存」し、再アップロードを案内
• 外部サービス側の問題 → タイムスタンプ付与を行っている外部企業へ問い合わせ（テンプレートも用意）

失敗原因のパターン、確認すべきステータス値、調査の分岐条件——これがステップごとに整理されている。Skillがあれば、初めてのパターンでも調査の道筋がわかる。
最初は雑なメモ程度だった。でもチケットを重ねるたびに、「あ、ここは補足が必要だな」「この注意点も書いておかないとハマる」と、Skillsは育っていった。

Skillsの成長

Skillsが増えるほど、1件あたりの調査時間は目に見えて短くなった。以前は1件に1〜2時間かかっていた調査が、Skillsがある分野なら15〜30分で終わるようになった。

ただし、これは「AIが賢くなった」からではない。調査のたびに「次も使えるな」と思った手順をファイルに書き残しただけだ。暗黙知を形式知に変える——地味で泥臭い作業の積み重ねでしかない。

3. AIの回答は信用できない——痛い失敗から生まれた「自己検証」

Skillsで効率化が進む一方、致命的な問題にぶち当たった。

AIの回答がそのままでは使えない。

Claude Codeに限らず、AIを業務で使っている方なら痛いほど経験していることだと思う。

「調査結果をそのままJiraに投稿して」と言えば、Claude Codeは流暢に回答を書いてくれる。でもそこには、検証されていない推測が事実として紛れ込んでいることがある。

ここでは実際にあった失敗を3つ挙げる。

失敗1: モデルクラスの名前空間を間違えた

app/models/配下のサブディレクトリにあるファイルに対して、Claude Codeはディレクトリ名をそのままnamespaceとして SomeModule::SomeModel というクラス名を出力した。しかし実際のクラス定義にはnamespaceがなく、正しくは単に SomeModel だった。

これは調査結果をもとに対応方針を上長に報告する場面で発覚した。間違ったクラス名を前提とした報告を上長に渡すところだった。

失敗2: 「記録されない」と断言したが、実際は大量に存在した

承認フローの調査で「承認フローモデルの変更履歴にupdateは記録されない」とSkillsに書いた。コードの一括削除処理の挙動だけを見てそう結論づけた。しかし実際にDBを叩いてみたら、updateの変更履歴レコードが大量に存在していた。

しかし実際にDBを叩いてみたら、updateの変更履歴レコードが24万件以上存在していた。 未検証の「存在しない」を事実として記載していたのだ。

失敗3: 抽出条件の見落としで変更履歴が欠落

ある調査で、お客様の承認フロー変更履歴を変更履歴テーブルから抽出することになった。変更前後の差分を出すために、特定の操作種別で絞り込みをかけた。しかし実際には、その絞り込み条件では捕捉できない操作パターンが存在しており、全体の約6%の変更履歴が結果から欠落していた。 お客様に共有する前に件数を照合して気づけたが、そのまま渡していたら「変更されていない」と誤った結論を導くところだった。

これらの失敗に共通するのは、AIが自信を持って間違えるということだ。「わかりません」とは言わない。流暢に、もっともらしく、間違った回答を出す。

この問題を解決するために、調査フローに 「自己検証（Devil's Advocate）」 というステップを追加した。

自己検証ルール
「お客様から"間違っています"と指摘が来た」という前提で自分の回答を疑う

1. モデル・クラス名はファイルのclass定義行を読んで確認する（推測禁止）
2. 「存在しない」「記録されない」はDBクエリで0件を実証してから断言する
3. データ抽出条件を変えた場合、変更前後の件数を比較して意図しない欠落がないか確認する
4. 未検証の項目は正直に「未検証です」と明示する

ポイントは、AIに「疑え」と言っても中途半端にしか疑ってくれないことだ。**「お客様から間違っていますと指摘が来た」**という具体的な状況を設定することで、初めて本気で検証してくれるようになった。

これをCLAUDE.md（プロジェクト全体の指示書）にも書き込み、過去の失敗事例も具体的に記載した。同じ過ちを繰り返さない仕組みを、AIの中に埋め込んだわけだ。

4. そして全自動化へ——毎時動く調査ロボットを作った

Skillsと自己検証の仕組みが整ったところで、次のステップに踏み出した。

「私がチケットを見つけて調査を依頼する」のではなく、「AIが自分でチケットを拾って調査を始める」ようにできないか？

Before / After

2つのロボが連携して動く

実装したのは、役割の異なる2つの自動プロセスだ。

調査ロボが調査して通知を送り、私がスタンプを押し、学習ロボがそれを拾って次の調査に反映する。この2つのループが独立して回ることで、調査のパフォーマンスを落とさずに学習機能を実現している。

調査/学習ロボの全体フロー

claude -p（ヘッドレスモード）をmacOSのlaunchdで自動起動する。調査ロボは毎時0分、学習ロボは15分ごとに動く。

確信度の5段階評価

調査結果には確信度を付与して、判断材料を可視化する。

実際のSlack通知はこう届く。

CRE-XXXXX: タイムラインに同じメッセージが表示される
  → 確信度: ★★★★★（確定）
  → 結果: 不具合ではなく正常動作。ユーザーが同一テキストを複数申請に入力
  → 調査ログ: CRE-XXXXX

CRE-YYYYY: インポートエラーファイルが破損
  → 確信度: ★★★★☆（ほぼ確定・ファイルサイズ未検証）
  → 結果: ライブラリの再シリアライズによるファイル破損
  → 調査ログ: CRE-YYYYY

このメッセージにスタンプでフィードバックをお願いします
✅ 採用  ✏️ 修正あり  ❌ 却下

学習ロボ——調査のたびに賢くなる

完了通知に私がスタンプを押すと、15分以内に学習ロボが検知して以下の処理を自動で行う。

処理が完了すると、元の完了通知のスレッドに「✅ フィードバック確認しました。正解として記録済みです。」のように返信が付く。どの通知が処理済みか一目でわかる。

たとえば、確信度★5で出した回答が実際に修正されていたら、「確信度の判定基準が甘い」という信号になる。修正が多い調査パターンがあれば、そのSkillの改善が必要だとわかる。使えば使うほど精度が上がる仕組みだ。

MCPで広がる調査範囲

Claude Codeの強みのひとつは、MCP（Model Context Protocol）で様々な外部サービスと接続できることだ。

Jira、Slack、Datadog、Notionなど複数のMCPを接続することで、調査の範囲と深さは大きく広がった。

「この現象、前にも誰かが報告していなかったか？」をSlackで探せる。コードだけ読んでも「なぜそう実装されているのか」がわからない時、Notionのドキュメントが決め手になる。調査の質は、アクセスできる情報源の広さで決まる。

安全策——最後の砦は人間

全自動化で最も怖いのは、間違った回答がお客様に届くことだ。だから安全策は多層的に設計した。

• 回答の自動投稿は一切しない。 AIが作るのはあくまでドラフト。Jiraのサブタスクに保存し、私が確認してから親チケットに投稿する
• DBは物理的にREAD-ONLY。 実行スクリプトにガードを組み込み、SELECT文以外は実行不可能にしている
• 確信度を5段階で明示。 調査結果に対して「確定」から「情報不足」まで5段階の確信度を付与し、判断材料を可視化する

ただ、これらは技術的な安全策にすぎない。本質はもっとシンプルだ。AIがどれだけ正確な調査をしても、その回答に「OK」を出して責任を負うのは人間だということ。この構造は設計思想であり、AIが進化しても変わらないと思っている。

5. 「人間にしかできない仕事」の正体

自動調査プロセスが動き始めて、調査業務の景色が一変した。

朝PCを開くと、Slackに「CRE自動調査完了レポート」が届いている。新しいチケットがあれば調査済みで、Jiraのサブタスクに調査ログと回答ドラフトが記録されている。ステータスも「エンジニア対応中」に変わっている。作業時間もClockifyに記録済みだ。

私がやることは、ドラフトを読んで確認し、問題なければ親チケットに投稿するだけ。

浮いた時間で、これまで手が回らなかったことに取り組めるようになった。お客様の問い合わせ傾向から機能改善が必要な箇所を洗い出して優先順位をつけ、社内向け管理ツールの機能として自ら開発する。APIキーの発行や金額の修正など、これまでCSがエンジニアに依頼していた作業をCS自身で完結できるようにする機能だ。。個別チケットの対処療法ではなく、根本原因にアプローチする仕事になる。

しかし同時に、どれだけ自動化が進んでもAIには任せられない領域がくっきりと浮かび上がってきた。

以前、同僚と「人に残る本質的な価値」について議論したことがある。その時に整理した軸が、CREの現場で驚くほど正確に当てはまっている。

責任の所在

AIが「この承認フローの設定が原因です」と調査結果を出しても、その回答が間違っていた時に責任を取れない。 お客様に謝罪する、上長に報告する、再調査を約束する——これは人格を持つ主体にしかできない。

これはCREの現場に限った話ではない。もっと大きな括りで考えてみる。たとえばAIが経営判断や投資判断まで担うようになったとして、その判断が失敗した時に誰が責任を取るのか。株主総会で頭を下げる、辞任する、社会的制裁を受ける——法人の意思決定には「責任を取れる人格」が必要で、これは法制度が変わらない限り人に残る。

自動パイプラインで回答ドラフトを自動投稿しない設計にしているのは、まさにこの理由だ。AIが出した回答に「私がOKを出す」というステップを挟むことで、責任の所在を人間に残している。

根源的動機——「なぜ」を決めるのは人間の欲望

AIは与えられた目的関数を最適化できるが、目的関数そのものを生み出すのは人の欲望だ。

「このチケットを調査して」と言えばAIは調査する。「この形式で回答して」と言えばその通りに書く。でも、「なぜこの問い合わせに30分以内に回答すべきなのか」「なぜこの機能の改善をPdMに提案すべきなのか」——その「なぜ」を決めるのは人間だ。

CREの仕事の中で、「これはエスカレすべきだ」と判断する場面がある。あるチケットではPdMに「Raw Logをお客様に提供できる仕組みが必要では？」と提案した。「この機能はあるべきだ」という根源的動機は、CSお客様と向き合ってきた経験から湧き上がるものだ。 AIにはこの動機を持てない。

他者との合意形成——信頼・感情・政治

ある問い合わせで、CSの方から「15〜30分meetで繋がせてもらえませんか？」と依頼があった。調査結果のログの見方を説明する場面だ。

技術的には単なるログの読み方。でも大事なのは、「この34時間という数字は何を意味するのか」を、相手が何をわかっていて何をわかっていないかをリアルタイムで感じ取りながら説明すること。

別のケースでは、SREチーム、情シス、CS、お客様の情報システム部門——複数の関係者を巻き込んでメール配信の調査を進めた。これは論理だけの話ではない。信頼や感情を読みながら、誰にどの順番でどんなトーンで伝えるか。 相手も人である限り、人が人と交渉する構造が残る。

6. 労働の価値の変質——「作業者」から「判断と責任の引き受け手」へ

ここまでの経験を通じて確信したことがある。

今後の労働は「作業の提供」から「判断と責任の引き受け」へシフトする。

忖度なしの厳しい見方をすれば、「人の判断が残る」ことと「多くの人に仕事が残る」ことは別物だ。CREの調査で言えば、AIが自動で10件のチケットを処理し、人間は「判断が必要な2件」に集中する——それは10人の調査員が2人で済むという意味でもある。

だからこそ、AIに任せられる作業を積極的に手放し、人間にしかできない判断・責任・関係構築にシフトできるかどうかが、個人としての生存戦略になる。

おわりに——次に自動化するのは何か

やったことは単純で、調査のたびに「これ次も使えるな」と思った手順をファイルに書き残しただけだ。それを繰り返していたら、いつの間にか自動で調査が回る仕組みになっていた。

正直、まだ課題は多い。調査がタイムアウトすることもあるし、確信度が低い結果も出る。外部システムとの連携がうまくいかずデバッグに時間を使った日もあった。

それでも、チケットが来てから回答ドラフトが出るまでの時間は確実に短くなった。その分、お客様への説明やエスカレの判断、機能改善の提案に時間を使えるようになったのは事実だ。

今後の展望としては、いくつかのテーマを考えている。

• 回答精度の向上: 確信度★4以上の割合を上げるために、自己検証ルールの強化と失敗事例の蓄積を続ける
• 類似チケットの自動検出: 過去の調査結果を横断検索し、「この問い合わせは以前のCRE-XXXXXと同じパターンでは？」と提案する仕組み
• エスカレ判断の補助: 「このチケットは調査だけでは解決できない。PdMへの機能改善提案が必要」という判断をAIが補助する

AIの進化は速い。今自分がやっている判断業務も、いずれ自動化できる部分が増えていくだろう。その時にまた「次は何を自分がやるべきか」を考えればいい。

AIに任せる → 浮いた時間で次の課題を見つける → それもAIに載せる

このサイクルを回し続けることが、この時代の働き方なんだと思う。

この記事が、AIを業務に取り入れようとしている方の参考になれば嬉しい。