Claude Codeを何から始めるか｜自動化する業務の選び方と、着手してはいけない順番

Claude Codeを導入すると決めても、すぐ実務へ進めるとは限りません。多くの企業が最初に悩むのは、機能は理解できたものの、自社のどの仕事を入口にすればよいのか決められないという問題です。

検索結果には、議事録作成、請求書の仕分け、日報の要約、データ照合など、実現できることを並べた記事が数多く見つかります。自社でも使えそうな例ばかりですが、候補を見比べるほど決断しにくくなります。できる業務の一覧だけでは、実行する順序までは決められないためです。

そこで選ばれがちなのが、現在もっとも工数の大きい仕事です。一見すると合理的ですが、当社の支援経験では、むしろこの選択が初回の自動化を未完成に終わらせる要因になっていました。

本稿では、候補業務を整理する4つの観点、実際に進める順番、さらに現段階では見送るべき対象を明らかにします。前提の分からない他社の削減率やROIは根拠にせず、数値は公式に確認できる仕様と当社自身の計測結果に限って扱います。

製品仕様の確認にはClaude Code公式のセキュリティ資料を用い、2026年8月30日時点の内容を反映しています。今後変更される場合があるため、導入時には公式情報の最新版を必ず確認してください。運用例は当社の実務を基にしていますが、取引先名、顧客名、金額は記載していません。

上位記事を実際に読んで見つけた空白

執筆に先立ち、「Claude Code 何から始める」「生成AI 業務自動化 優先順位」などで検索し、上位の記事を一つずつ確認しました。推測だけで論点を設定しないためです。

最初の記事は、非エンジニアの事例を幅広く紹介する大規模な内容でした。分量は推定18,000〜20,000字で、7件の事例のほか、導入の道筋、任せない仕事、典型的な失敗、セキュリティ設定まで説明されています。結果に誤りがあっても再実行できる仕事なら任せられるという整理があり、可逆性の発想も含まれていました。しかし、その観点は可否の線引きに使われるだけで、開始順位を定める方法には発展していません。業務別のROIや削減率も掲載されていたものの、計測条件を検証できないため本稿では引用しません。

次の記事は10事例を載せた推定35,000字の解説でした。Phase 1〜3の導入工程があり、最初はもっとも時間のかかる1業務に集中するとされています。この方針は本稿の考えと逆です。元データを更新せず別ファイルへ出力するという実装面の注意はある一方、可逆性を選定条件としては扱っていません。時間削減や回収期間も示されますが、前提を確認できないため根拠には用いません。

3つ目は、AI導入の優先順位を主題にした推定8,500〜9,000字の記事です。対象に適した条件を、定型性、情報整理中心、人による最終確認という3点で説明しており、実務に即した妥当な内容でした。ただし、失敗後に戻せる度合いと、入力材料がどこに存在するかは基準に含まれていません。

4つ目はビジネスメディアによる実践的な解説でした。何も整理せず一括で任せる危険性と、具体的なゴールを伝える必要性が中心です。依頼方法の参考にはなるものの、その前に必要な対象業務の選定までは扱っていません。

以上から見えたのは、AIと相性のよい仕事の特徴は、すでに十分説明されているということでした。定型的で、情報を整える比重が高く、人が最後に確認できることについて、本稿も同じ立場です。

一方、条件を満たす候補が社内に20個あった場合、最初の1個をどう選ぶかは明確にされていません。また、最初の選択を誤ると、現場でどんな停滞が生じるのかも空白です。以下では、この2点を掘り下げます。

効果が大きい業務から始めると、なぜ止まるのか

候補を絞る際、工数が最大の業務を最優先にする会社は少なくありません。費用対効果だけで見れば、自然な結論です。

ただし、社内でもっとも時間を要する仕事には、ほぼ共通して次の性質があります。

一つ目は、途中で決断を求められる回数が多いことです。工数が膨らむ原因は単純な作業量だけではなく、処理方法を考える場面が繰り返し現れる点にもあります。人が判断する箇所が多ければ、導入後も確認負担が残り、自動化による削減効果は伸びません。

二つ目は、成果が組織の外へ届くことです。請求、提案、顧客連絡、一般公開など、重い業務の先には社外向けの出力がよくあります。自動実行で誤りを出せば、発見後に完全な撤回はできません。そのため設計と確認が厳重になり、初回には重すぎる仕組みになります。

三つ目は、入力情報が各所に分散していることです。必要事項がメール、表計算、共有フォルダ、チャット、紙へ散っていれば、処理の自動化より先に収集経路を整えなければなりません。本来簡略化したかった作業に入る前に、情報を集める別の仕組みが必要になります。しかも収集部分は、想定の3倍ほど手間取ることが珍しくありません。

四つ目は、関与する人や部門が多いことです。部署を横断する仕事では、制作中に書式変更や不要項目が判明します。関係者との認識合わせが発生するたび、実装は中断します。

これらが同時に存在すると、着手から2週間を過ぎても、利用できる成果が何もない状況になり得ます。初回が完成しないまま、Claude Code自体が自社に適さないと判断されてしまいます。

当社が関わった現場でも、同様の止まり方を複数回見てきました。担当者の力量や製品性能ではなく、入口に置いた業務との相性が原因です。

そこで初回は、期待効果の大小よりも、結果を短期間で検証できるかを優先します。最初に得たい成果は工数削減ではなく、自社で形にし、問題があれば自社で修正できたという実績です。高効果の対象は、その土台を作った後でも遅くありません。

業務を並べ替える4つの軸

候補が並んだら、当社では4つの観点から順序を整理します。細かな採点表にはせず、各観点について質問へ答えるだけで判断します。

軸1：頻度 ── その業務は毎日あるか

日々繰り返す仕事なら、作成した次の日には動作を確かめられます。不具合も翌日の実行を見て改善できます。検証と修正を短い間隔で回せることが、初回では最優先です。

月次や四半期ごとの仕事は、次回までに細かな操作や設計意図を忘れがちです。作成者自身も判断理由を思い出せない可能性があります。低頻度の業務に自動化価値がないのではなく、初手に置くと学習周期が長すぎるのです。

軸2：判断の量 ── 決める場面がいくつあるか

この観点で数えるのは、条件に応じて人が処理を選ぶ場面です。判断が皆無の仕事はまれですが、判断箇所を具体的な数で把握できるかが重要です。

判断点が3か所だと説明できるなら、そこに人の確認を設けられます。反対に、いつも状況が違うとしか説明できない仕事は、手順として整理されていません。その場合は自動化より先に、現在の進め方を文書化する必要があります。

軸3：取り返しやすさ ── 間違えたとき元に戻せるか

4つの中で、今すぐ対象にできるかを最も強く左右する観点です。当社では、誤作動による影響を次の4段階に分けます。

• 自分の端末内だけでファイルが変化した：直前の版へ戻せるため、影響が最小の状態です
• 共有領域のデータが更新された：履歴があれば復元できますが、履歴がなければ回復できません
• 社内メンバーの目に触れる場所へ出た：内容は訂正できても、閲覧した人の認識までは消せません
• 組織外へ送られた：削除後も複製や引用が残り得るため、完全には巻き戻せない段階です

初回は、影響が最小の範囲で完結する対象を選びます。設定による保護が有効なのは上から2段階ほどで、社外に出た情報を設定で回収することはできません。誤りを事故へ発展させない設計は、AIが間違えても事故にならない業務の作り方｜承認・下書き止め・取り消せる設計で詳しく説明しています。

軸4：材料の在り処 ── 必要な情報が1か所にあるか

忘れられやすいものの、実装時に大きく効く観点です。本来の処理が単純でも、入力を集める作業の方が重くなるケースがあります。

調べ方は難しくありません。その仕事を完了するまでに開く場所の数を数えます。1〜2か所なら早く始められますが、5か所以上なら、まず情報の保管方法を整える課題として扱います。

この条件は既存記事であまり触れられませんが、実際の導入では早期に壁となります。処理を任せようとしても、必要な入力が揃わず始められないことは決して例外ではありません。

最初の1本が満たすべき4条件

4つの観点で検討した結果、当社が初回の対象に求める要件は以下になります。

• 日々発生する：翌日には動きを確認でき、修正結果もすぐ試せます
• 元へ戻せる：誤りが起きても、自分の管理範囲で復旧できます
• 社内だけで完結する：作成物が顧客や取引先へ直接渡りません
• 入力元がまとまっている：参照先が1〜2か所に限定されています

すべてに当てはまりやすいのは、情報を見つける仕事、または内容を集約する仕事です。派手さは必要ありません。初回で確認するのは大幅な効率化ではなく、作成、修正、停止の発見を自分たちで行えるかという3点です。

なお、対象業務を小さくしなければならないという意味ではありません。過去の連絡、前年資料、類似案件の前例などを探す時間は、合計すると無視できません。1回は数分でも、毎日繰り返せば負担は積み上がります。検索は、一見細かな作業に潜む大きな工数を、低リスクで減らせる対象です。

着手の順番は「探す→畳む→下書き→定期実行」

当社では、2つ目以降も含めて次の段階に沿って進めています。

1本目：探す

端末内の資料や過去の連絡から、条件に合う情報を検索します。特別な準備が少なく、期待どおりでなくても実害につながりません。検索結果が不十分でも、外部へ何かが送られることはないためです。

この段階では、適切な依頼条件を組み立てる感覚を得られます。条件の細かさや対象期間の区切り方を試し、取りこぼしを減らします。この経験がないまま先へ進むと、問題の原因が依頼文か対象業務か判断できません。具体的な依頼例は、Claude Codeでまず効くのは「作る」より「探す」｜社内の資料・過去のやりとりを横断で見つけるで紹介しています。

2本目：畳む

週報、月ごとの状況、問い合わせ傾向など、複数の記録を一つの資料へ整理します。この段階には、守るべき重要な原則があります。

AIに件数や合計値そのものを計算させないことです。数値集計が必要なら、再実行できる計算手段を作らせ、実際の計算はその仕組みで行います。AIが担うのは、確定した数値を分かりやすく説明する文章です。

そうする理由は、計算の再現性がない、誤りの発生箇所を追えない、自然な文章の中へ誤った値が紛れ込むという3点です。特に最後の問題は、読み返しても違和感を持ちにくいため危険です。実務手順は、経営企画のAI活用｜散らばった数字を毎月1枚のレポートに畳むClaude Codeの手順で解説しています。

3本目：下書きにする

次に、社外で使う文章の草案作成へ進みます。外部向け成果物を初めて扱う段階ですが、自動化の範囲は下書き保存までとし、公開や送信は人が操作します。

安全性を高めるには、規則に「送らない」と書くだけでなく、送信機能をそもそも与えない構成にします。注意事項は忘れる可能性がありますが、存在しない機能は実行できません。メールの境界はClaude Codeでメール業務を軽くする｜「読む・探す・下書きする」までに止める設計、問い合わせ対応への展開はカスタマーサポートのAI活用｜問い合わせ対応をどこまで任せるか、Claude Codeで作る「下書き止め」の設計を参照してください。

4本目：毎朝動かす

最初の3段階で手順が安定した処理だけを、自動スケジュールへ移します。作業内容が固まっていない時点で定期化すると、誤った手順が毎日反復されます。

定期処理には必ず、エラーを無視しない仕組み、実行時刻と処理内容の記録、失敗を発見できる場所への通知を揃えます。どれかが欠けると、停止しても把握できません。詳細はAIの作業を毎朝自動で動かす｜定期実行の作り方と、壊れたときに気づく仕組みで確認できます。

段階を省略して定期実行から着手すると、初成果が「停止を検知できない自動処理」になりかねません。これは必ず避けるべき状態です。

今はまだ着手しない業務、6種類

AIに任せない仕事を紹介する記事は多いですが、ここでの主題は禁止ではなく着手時期です。将来も一切扱わないのではなく、必要な準備を終えるまでは選ばない対象として整理します。

1. 外に出る文章を機械が送る業務

公開や送信を実行すると、誤りを後から完全には回収できません。草案を人が確認する流れが安定し、確認行為が日常の習慣になった後でなければ、自動送信へ進むべきではありません。

2. 確定した数字を書き換える業務

締め処理済みの月次データ、確定台帳、提出を終えた書類などは、破損しても直ちに判明するとは限りません。次回の締めや監査まで見逃されるおそれがあります。

先に、原本を復元できる保存方法と、更新可能な列を限定する仕組みを用意します。経理照合の例は、経理の月次をAIで軽くする｜請求書・経費・入金の突合をClaude Codeで「手元の表のまま」回すで解説しています。

3. 個人情報が主役の業務

応募書類、人事考課、健康関連データを扱うなら、AIへ渡す前に個人情報を除去する工程を、正式な作業手順へ含めることが開始条件です。

単に担当者が気をつけるのでは不十分です。情報を除いた別ファイルがなければ後続処理を開始できない流れにします。実装方法は、人事・労務のAI活用｜手続きと規程を、個人情報を渡さずにClaude Codeで回すで扱っています。

4. 月に1回しかない業務

見込める効果が大きくても、次回までの間に操作手順や改善の感覚が薄れます。年4回なら検証機会はさらに減ります。日常業務で型を身につけてから長周期の仕事へ移る方が、総合的には早く進みます。

5. 材料が5か所に散っている業務

情報収集が作業の中心になり、肝心の自動化へ到達できません。まず保管先を整理し、参照場所を1〜2か所へ集約します。重要な改善ではありますが、AI活用とは別プロジェクトとして進める方が論点を分けられます。

6. 評価・合否を決める業務

このタイプだけは準備順ではなく、自動化の範囲外とします。理由は、根拠を後日説明しにくいこと、既存の偏りを再生産し得ること、そして判断結果が正解だったか事後検証できないことの3つです。

最後の理由は特に重大です。通常の処理なら誤りを後から確認できますが、評価や合否では、別の結論が正しかったと証明する方法がありません。当社ではAIの役割を、意思決定に必要な情報の整理までに限定しています。

「やらない」と決めた判断こそ記録に残す

実施対象を選ぶと、同時に今回は開始しない候補も生まれます。口頭だけで見送ると、3か月後に理由が分からなくなり、同じ検討をやり直すことになります。

そのため当社では、保留にした根拠を文章で保存します。実際の事例を紹介します。

自社メディアの企画一覧から毎日いくつかのテーマを選び、記事制作へ進めています。ある業種を対象とする企画が候補に上がった際、制作へ進めず保留扱いにしました。

その理由は、当社がその業種について語れる一次情報を持っていなかったからです。関連事業との接点はあっても、日常業務は別の担当者が行っており、現場特有の難所を自分の経験として説明できませんでした。

記録したのは保留の結論だけではなく、再開には何の情報が必要なのかという条件までです。そのため企画は削除されず、材料が集まった時点で再検討できます。

記事制作に限らず、自動化候補も同様です。再開条件とともに残した見送り理由は、将来使える判断材料になります。「参照先が2か所になったら開始」「草案確認を3か月継続できたら次段階へ」と具体化すれば、次の担当者が検討を一から繰り返さずに済みます。

製品の仕様が、着手順に影響する3点

対象業務だけでなく、Claude Codeが備える仕様も開始順に関係します。公式資料を基に、現場で重要となる3点を整理します（確認日：2026年8月30日）。

1. 既定は読み取り専用である

公式資料によると、Claude Codeは初期状態で厳格な読み取り専用権限を採用しています。編集やコマンド実行が必要になった場合、利用者へ明示的に許可を求めます。

この仕様は、導入の入口として検索を選ぶ方針と相性がよいものです。「探す」だけなら、大幅な権限変更をせず開始できます。反対に更新処理を初手にすると、業務改善の前にアクセス権の設計から議論しなければなりません。

2. 書き込める範囲は起動した場所で決まる

公式の説明では、書き込み可能なのは起動フォルダとその配下に限られ、親階層を変更するには明示的な許可が必要とされています。

これは、業務単位の境界づくりに活用できる特徴です。案件別または部門別にフォルダを設け、その中から起動すれば、情報が混ざらない状態を構造で作れます。初回候補を選ぶ際にも、一つのフォルダ内で完結するかを確かめると、その後の運用が容易になります。

3. 速く進むモードほど、戻せない操作を自動承認する

公式セキュリティ資料では、編集を自動で認めるモードについて、ファイル編集だけでなく、mkdir、touch、rm、mv、cp、sedなど、あらかじめ定められたファイルシステム用Bashコマンドも作業ディレクトリ内で自動承認されると説明されています。

対象操作には、削除や移動も含まれます。つまり、確認を減らして速度を上げるほど、元に戻しにくい処理も無確認で進みやすい関係です。

したがって、初回の対象ではこのモードを選ばない方が安全です。操作を一つずつ承認すれば、処理内容を理解しながら進められます。高速化は手順を把握した後で十分です。詳細はClaude Codeの権限設計を実例で｜settings.jsonとhooksの書き方の勘所を参照してください。

材料の在り処を先に確かめる

4観点の中でも、事前調査による効果が大きいのが情報源の場所です。開始を決定する前に次の4項目を調べれば、大幅なやり直しを避けられます。

• 情報源は何か所に分かれているか。1〜2か所なら開始しやすく、3〜4か所なら先に収集手順を設計します。5か所以上であれば保管場所の整理を優先します
• 機械で読み取れる状態になっているか。紙面や画像内の文章は直接処理できないため、文字を抽出する工程が追加されます
• 毎回同一の形式で届くか。取引先によって書式が異なるなら、形式を揃える段階が必要です。ただし完全統一を開始条件にすると、統一作業が終わらず停滞します。元の書式を保ったまま受け取り、項目の意味を対応させる表を1枚用意する方が現実的です
• 社外から受け取った資料を含むか。メール、応募書類、取引先の添付物などは、命令ではなく処理対象のデータとして扱わなければなりません

4つ目には注意が必要です。外部文書には、AIへ命令するように見える文章が埋め込まれている可能性があります。公式資料は複数の防御策を案内していますが、対策によって危険は大きく減らせても、あらゆる攻撃を完全に防げるシステムはないという趣旨も明記しています。

そのため、不正な指示を見落とした場合の影響まで想定して設計します。社外文書を読む処理を初回に選ばないのは、このリスクがあるためです。対策はClaude Codeに社外の文書を読ませる前に｜メール・Webに埋め込まれた「AIへの指示」の防ぎ方で詳しく説明しています。

成否の判定を「削減時間」で置かない

初回の成果を時間削減だけで評価すると、取り組みの成否を見誤ります。

第一の理由は、初回に選ぶ仕事では大幅な短縮が起きにくいことです。毎日起こり、元に戻せ、社内で完結する対象は、1回あたりの所要時間がもともと短い傾向にあります。それを低効果と評価すれば、安全な選定方針まで誤りとされてしまいます。

第二の理由は、作成者自身の計測では結果が良くなりやすいことです。仕組みと操作を熟知した人が速く使えるのは当然であり、別の担当者も再現できるかを見る必要があります。

当社では、初回を次の3項目で評価します。

• 作成者とは別の人も実行できたか。説明を読んだ他の担当者が同一の結果へ到達できるかを確認します
• 期待外れの出力を自力で修正できたか。他者へ依頼せず、原因を分けて調べられたかを見ます
• 処理停止を検知できたか。あえて動かない状況を作り、それを把握できる仕組みがあるかを試します

すべて満たせば次の対象へ進めます。一つでも満たさなければ、対象数を増やす前に不足を解消します。時間削減の計測方法は、Claude Codeの費用対効果を社内で説明する｜時間削減の測り方で別にまとめています。

当社が実際に着手した順番と、その理由

当社では、経営、経理、人事、総務などのバックオフィスを少人数とAIで運営しています。実際の導入も段階を分けて進めました。

最初の対象は、その日の予定を朝に1枚へ整理する仕組みでした。カレンダーと未完了タスクを確認し、当日の進行案を表示します。目立つ効率化ではありませんが、毎朝発生し、元へ戻せ、外部送信がなく、参照先もカレンダーとタスク管理の2か所だけという4要件を満たしていました。

この経験から、タスクは受信箱だけを対象にするなど、社内固有の暗黙知を明文化しなければ出力は安定しないと分かりました。その学びは、後続のすべての仕組みに活用されています。

2つ目に作ったのは文書の草案作成です。メールや資料の案を作り、ファイルへ保存するところで止めます。送信権限は与えていません。この段階で、誰の立場から書くかを先に指定しないと表現が揺れるという、当社特有の課題が見つかりました。

3つ目は、分散した記録を一つに集約する処理でした。数値のカウントは再現可能な道具、説明文はAIという役割分担を、ここで確立しました。

定期実行と外部への更新は4つ目以降です。前段階を経験してから、毎朝の自動処理や、人の承認後に外部へ反映する処理を始めました。

結果として、朝の工程表を入口にした判断は適切だったと考えています。仮に顧客向け提案書を最初に選んでいれば、判断点が多く、社外向けで、情報源も5か所に分かれているため、現在も完成していなかったでしょう。

2本目以降に起きる、想定外の詰まり

推奨順序に沿っても、問題がなくなるわけではありません。ここでは当社が遭遇した事例を挙げます。どれも明確な失敗表示ではなく、正常に見えるのに実態が違うという形で発生しました。

取りこぼしが「該当なし」の顔をする

長期間の記録を取得した際、1回の取得上限で処理が途中終了しているのに、画面上は正常な結果に見えることがありました。

12件と表示されても、全件が12件なのか、上限によって12件までしか返らなかったのか判別できません。期間を半月単位に分割し、区間ごとの件数を残して比較する方法で対処しました。たとえば5月前半のみ0件という偏りは、横並びにして初めて発見できます。

手で直したときと機械が書いたときで、反応が変わる

表計算の更新をきっかけに動く処理では、人の手入力には反応する一方、自動書き込みでは開始されない現象が起きました。エラー表示はなく、後続処理だけが実行されません。

更新時の反応だけに頼らず、一定時間ごとに状態を確認する別処理も追加しました。一方が動かなくても、もう一方で未処理を拾えます。

通知が多すぎて、業務が止まる

ある処理の初回稼働で過去データを一括処理した結果、通知が大量に届き、必要な連絡がその中へ埋もれる事態が起こりました。

そこで通知をやめ、記録用シートと処理済みマークだけに結果を残す方式へ変更しました。通知量を増やしても安全性が高まるとは限りません。誰も確認しない通知は、存在しないのと変わりません。

静かに止まる

特に見つけにくい問題です。当社では、実行環境の構成、設定ファイルを読む場所の相違、端末の休止、外部接続の制約、通知先への未参加という5種類の原因で停止を経験しました。

いずれも通常画面には異常が現れません。そのため、失敗時だけでなく正常終了時にも通知する形にしました。普段届くことを確認できて初めて、届かなくなった変化を検知できます。

部署が複数あるときの順番

これまでは個人または単一部門での利用を想定しました。全社など複数部署へ展開する際には、別の優先順位も必要です。

基本は、負担が最大の部署ではなく、入力材料が整った部署を先にすることです。強く困っている現場ほど情報管理も混乱している場合があります。後段に回して準備を整えた方が、結果的に早く支援できます。

当社が支援する際は、以下の順に状況を確認します。

• 必要資料がデジタル化されているか。紙が多い部署では、文字を読み取る前処理が追加で必要です
• 部門内に業務手順を言語化できる人がいるか。どこで困るかを説明できる担当者がいれば、設計は大きく進みます
• 成果のうち社外向けが占める割合はどの程度か。内部資料が中心の部署ほど、導入初期に適しています
• すでに個人利用している社員が存在しないか。該当者がいれば、利用状況を把握し、会社契約へまとめる作業が先です

最後の確認は特に忘れられます。新規配布だけを想定すると、個人契約ですでに利用中の社員が管理対象から外れます。放置すれば会社共通の設定が適用されない利用環境が残ります。集約方法は社員が個人契約でClaude Codeを使っている｜把握の仕方と、会社契約へ寄せる手順、全社導入の流れは情シスのためのClaude Code導入設計｜全社展開の順番と守り方で紹介しています。

最初の30日で進めること

ここまでの考え方を、導入開始からの工程に落とし込みます。

1週目は、候補を出して4観点で整理します。業務を10個ほど挙げ、それぞれについて頻度、判断数、復元可能性、情報源の場所を確認します。採点は不要です。質問に答えられない候補は、現在の進め方がまだ手順として表現できていないと判断します。

2週目は、4要件に合う1業務を選び、検索から試します。毎日発生する、取り消せる、外へ出ない、材料が1か所という条件で候補を絞ります。この段階は完成を目指すのではなく、適切な頼み方を体得する期間です。

3週目は、成功した方法を文書化し、別担当者に試してもらいます。依頼方法を手順として保存して、作成者以外が実行します。別の人が止まった箇所こそ、手順書へ追加すべき情報です。

4週目は、次の対象を選び、保留候補も記録します。作成者以外も動かせたか、自力で修正できたか、停止を発見できたかという3条件を確認し、すべて満たせば2つ目へ進みます。同時に、見送った仕事、その根拠、再検討する条件を残します。

最初の30日で完成する仕組みは、多くの場合1つです。それで問題ありません。自社だけで作成と修正を経験すれば、2つ目から進行速度が上がります。最初から大規模な業務を選び、2か月停滞すると、導入検討そのものが終わる可能性があります。

よくある質問

Q. 効果の大きい業務を後回しにすると、社内の理解が得られないのでは？

確かに懸念されやすい点です。しかし合意形成に有効なのは、大きな予測値より、実際に動作するものを示すことです。2か月間検討だけを続けるより、小規模でも毎朝稼働する成果を見せる方が、次の予算につながります。稟議で確認される内容はClaude Codeの導入稟議を通す｜起案書に書く6項目と、決裁者に必ず聞かれることに整理しています。

Q. 4軸で並べても、候補が同点になったらどうしますか？

同じ評価になった場合は、情報源が少ない方を先に選びます。残る3条件が同じであれば、参照場所が少ない対象ほど早く確実に動かせます。それでも差がなければ、利用者がより負担に感じている仕事を選びましょう。日々改善を続ける意欲も、成功に影響します。

Q. 1本目が失敗したら、導入をやめるべきですか？

一度の失敗だけで中止する必要はありません。最初に、対象の選定と依頼方法のどちらに原因があるかを切り分けます。工数の大きな仕事を初回にした場合は、選択が重すぎた可能性があります。より安全で単純な対象へ替えて再検証できます。原因別の確認方法はClaude Codeが動かない・止まるとき｜非エンジニアの症状別つまずき対処で説明しています。

Q. すでに他のツールで自動化している業務があります。置き換えるべきですか？

問題なく稼働している仕組みを、無理に交換する必要はありません。確認すべきなのは、修正できる担当者と、停止を検知する担当者が明確かどうかです。両方が決まっていれば、既存環境を維持する方が安全です。使い分けはRPAとAIエージェントは何が違う？すでにRPAがある会社の使い分けで整理しています。

Q. 情報の取り扱いは、着手前にどこまで決めればいいですか？

社内資料だけを検索する初回であれば、最低限、起動に使うフォルダを事前に決めるところから始められます。利用範囲を広げる前には、入力可能な情報の境界を定めてください。判断基準はClaude Codeで情報漏洩を防ぐ｜入れてよい情報・いけない情報の線引きで確認できます。

Q. 社内に教えられる人がいません。何から手を付けますか？

初回は、専門の指導役がいなくても試せる範囲に絞ります。利用者を増やす段階では、画面操作よりも、判断のルールを教材にする方法が有効です。画面構成や名称は変化しても、判断原則は比較的長く使えるからです。展開方法はClaude Codeの社内教育をどう組むか｜3か月で使える人を増やす順番をご覧ください。職種別の学習素材が必要なら、実務で使えるAI実践研修も選択肢になります。

まとめ

本稿の重要点を振り返ります。

• 最大工数の業務を初手にすると停滞しやすくなります。判断点、外部出力、分散した情報源を抱えていることが多いためです
• 候補は4つの観点から整理します。頻度、判断の量、復元のしやすさ、材料の場所で比較し、開始可否は特に復元可能性で見極めます
• 初回は、日々発生し、元へ戻せ、社外へ出ず、入力元が1か所の仕事を選びます。多くの場合、検索または情報集約が該当します
• 実施順は、検索、集約、草案作成、毎朝の定期処理です。段階を飛ばすと、停止を把握できない自動処理が先に生まれます
• 現段階で見送る対象は6タイプです。5タイプは準備が整えば開始できますが、評価や合否の決定は自動化対象に含めません
• 保留理由には、再開条件も添えて保存します。次回に同じ議論を最初から行う無駄を防げます
• 初回評価の中心は短縮時間ではありません。別の人が実行できるか、自力で修正できるか、停止を検知できるかという3項目で判断します

導入が定着するか止まるかは、担当者の能力よりも、最初に対象とした業務の特徴に左右されることがあります。日常的に発生し、規模を抑えられ、失敗後に戻せる仕事を入口にしてください。