Claude Codeで開発する｜業務投入までの進め方

Claude Codeに指示を出したら、想定していたものが動いた。ここまでは、多くの会社が到達しています。問題はその次です。「動いた」ものを、明日から社員が毎日使う道具にできるか。ここで足が止まります。

止まる理由ははっきりしています。動かすことと、業務に載せることは別の仕事だからです。誰が直すのか、間違った結果が出たときにどう気づくのか、作った人が辞めたらどうなるのか。これらは、AIが答えを出してくれる領域ではありません。

この記事は、Claude Codeで「試しに動かす」段階を終えた方に向けて、実際に業務で使うものを開発する一連の流れを6つの工程に分けてまとめました。要件の詰め方、CLAUDE.mdへの前提の書き残し方、複数ファイルにまたがる変更の進め方、人が必ずやる確認、設計の残し方、引き継ぎと運用までを扱います。

あわせて、自社で作るべきものと外に出すべきものを分ける判定表と、自社で抱えきれなくなったときのやめ時も示します。Claude Codeがあれば開発会社が要らなくなる、という話はしません。そういう記事は現場で役に立たないからです。機能名・プラン・料金の記述は、2026年8月時点のAnthropic公式ドキュメントの原文に合わせています。

まだ導入前の方はClaude Codeの始め方を、何を任せられるかの全体像はClaude Codeでできることを先にお読みください。使い捨ての小さな道具を作る話はAIでアプリを作るで扱っています。

結論｜作るより残す方が難しい

先に結論を書きます。Claude Codeを使った開発で難しいのは、コードを書くことではなく、コードを残すことです。

Claude Codeは、日本語で指示すればファイルを読み、書き、コマンドを実行し、結果を確かめながら作業を進めます。作る速度は、人が手で書いていた時代と比べものになりません。だから「作れるかどうか」はもはや論点ではなくなりました。

代わりに論点になったのは、次の3つです。

1. 出てきたものが正しいと、どうやって確かめるか
2. 壊れたとき、誰が、何を見て直すか
3. 作った人がいなくなっても、業務が回るか

この3つに答えられないまま業務に載せると、半年後に「動いているが誰も触れないもの」が社内に残ります。これは、AI以前の内製でも起きていた事故です。作る速度が上がった分だけ、この事故も速く増えます。

逆に言えば、この3つに答えを用意する作業こそが「開発」です。以降の6工程は、すべてこの3つに答えるための手順だと考えてください。

試す段階と開発段階の違い

まず、自分がどちらの段階にいるかをはっきりさせます。ここが曖昧なまま進むと、試作の作法のまま本番に載せることになります。

「動いた」は開発の1割

試す段階のゴールは「できるかどうかの確認」です。自分のパソコンで、自分のデータで、自分が見ている前で動けば合格です。ここは1日で終わります。

開発段階のゴールは「他人が、別の日に、別のデータで使っても壊れないこと」です。求められるものが変わるので、必要な作業も変わります。体感として、動くまでが全体の1割、残り9割が確認と記録と引き継ぎです。

この比率に驚く方は多いのですが、これはAIを使っても変わりません。むしろAIを使うと最初の1割が数十分に縮むため、残り9割の存在が目立つようになります。

業務投入で増える3つの仕事

試す段階には無かったのに、業務投入では必ず発生する仕事が3つあります。

増える仕事	何をするか	やらないとどうなるか
正しさの検証	手作業の結果と突き合わせ、一致することを確認する	間違った数字が、気づかれないまま社外に出る
例外の処理	空欄・重複・想定外の様式が来たときの動きを決める	月末の忙しい日に止まり、手作業に逆戻りする
記録の作成	何を作ったか、なぜそう決めたかを文書で残す	半年後、作った本人も含めて誰も直せなくなる

3つ目が最も軽視されます。動いているものを前にして文書を書くのは、心理的に「無駄な作業」に見えるからです。しかし現場で問題になるのは、ほぼ確実に3つ目です。

この記事が扱う範囲

本記事が扱うのは、社内の業務を動かすためのツールやスクリプトを、自社で開発して運用に載せるまでです。顧客に販売するソフトウェア、基幹システムそのものの置き換え、金銭や法令に直結する処理は扱いません。それらは後述する判定表で「外に出す」側に分類されます。

また、使い捨ての処理を作る話、つまり1回だけ使って捨てるスクリプトについてはバイブコーディングとはで扱っています。本記事は、捨てずに使い続けるものが対象です。

開発の全体像｜6つの工程

業務に載せるまでの流れを6つに分けます。順番に意味があるので、飛ばさないでください。

工程	やること	主にやるのは	目安の時間
1．要件を詰める	入力・出力・例外・受入条件を文章にする	人	3時間から1日
2．前提を書き残す	CLAUDE.mdにプロジェクトの決まりごとを書く	人（下書きはAI）	1時間から2時間
3．作る	計画を立てさせ、小さく区切って実装させる	AI	数時間から数日
4．確認する	手作業と突き合わせ、例外を試し、直せるか点検する	人（一次抽出はAI）	実装と同じかそれ以上
5．設計を残す	何をどう決めたかを4点セットで文書化する	人（下書きはAI）	2時間から3時間
6．運用に乗せる	担当・置き場所・停止時の手順を決めて配る	人	2時間から半日

表を見て気づいてほしいのは、AIが主役なのは工程3だけだということです。残り5工程は人の仕事です。ここを勘違いすると、工程3だけをやって「開発が終わった」と思い込むことになります。

工程ごとの担当の分け方

IPAは、ソフトウェア開発におけるAIの活用場面として、対話型AIを用いた要件定義、議事録管理、生成AIによるプログラム開発（コード生成、ペアプログラミング等）、レビュー、AIによるテストとテストデータ作成を挙げています（出典：IPA「AIを用いたソフトウェア開発」）。つまり、AIは工程3だけでなく、要件定義にもレビューにもテストにも入り込めます。

ただし「入り込める」ことと「任せきれる」ことは違います。当社が支援するときは、次の線引きを最初に決めてもらっています。

作業	AIに任せてよいか	理由
要件の下書き・抜け漏れの指摘	任せてよい	人が読んで取捨選択する前提が成立する
要件の確定（何を作らないかの決定）	人が決める	業務上の優先順位はAIには判断できない
コードを書く・直す	任せてよい	結果を検証する手段が別にある
レビューの一次抽出	任せてよい	見落としを拾う用途に向く
本番データで動かす判断	人が決める	取り返しがつかない
業務に載せる最終判断	人が決める	責任の所在を曖昧にできない

レビューをどこまでAIに任せるかは、論点が多いためAIコードレビューの使い方で別途整理しています。

工程を飛ばすと何が起きるか

実際によく飛ばされるのは工程1と工程5です。それぞれ、飛ばした結果は決まっています。

• 工程1（要件）を飛ばすと、作り直しが3回発生します。「これじゃない」が3回来る、という意味です。1回あたり数時間が消えます
• 工程5（設計を残す）を飛ばすと、最初の修正依頼が来た日に止まります。中身を読んだことがないので、どこを直せばいいか分からないためです

工程2を飛ばした場合は、その場では困りません。困るのは2回目以降のセッションからです。毎回同じ説明を最初から書くことになり、しかも毎回少しずつ違う書き方をするので、出てくるものが揺れます。

工程1｜要件を詰める

最初の工程です。ここで書くのは仕様書ではありません。A4で1枚に収まる、決めごとのメモです。

決めるのは入力と出力と例外

要件で決めるべきことは、突き詰めると3つしかありません。

1. 入力：何を渡すか。ファイルの形式、置き場所、1回あたりの件数、誰が用意するか
2. 出力：何が出てくれば成功か。形式、項目、並び順、保存先、誰が受け取るか
3. 例外：想定外が来たときどうするか。止めるのか、飛ばして続けるのか、印を付けて後から人が見るのか

3つ目が最も抜けます。そして、業務で壊れるのはほぼ例外の扱いです。「取引先が増えて様式が変わった」「金額欄が空だった」「同じ伝票番号が2件あった」といった事態は、必ず起きます。

例外の洗い出しには、AIとの対話が有効です。次のように聞くと、自分では思いつかない条件が出てきます。

この処理で、入力データが想定と違ったときに起きうるパターンを
20個挙げてください。件数・空欄・重複・文字種・日付の形式・
ファイルが開かれている場合など、実務で起きやすい順に並べてください。
それぞれについて、止めるべきか、飛ばして続けるべきかの案も付けてください。

出てきた20個のうち、実際に対応するのは5個か6個で構いません。大事なのは、対応しないと決めた14個を「対応しない」と明記することです。ここが後から効きます。

受入条件を先に書く

要件メモに必ず入れてほしいのが、受入条件です。「これが成立したら完成とする」という条件を、作り始める前に書きます。

Anthropicの公式ドキュメントは、Claudeに検証手段を与えることを最重要の実践として挙げています。テスト、ビルド、リンター、出力を正解データと突き合わせるスクリプト、スクリーンショットの比較など、合否が返ってくるものを渡すと、Claudeが自分でその検証を回して直すまで繰り返すと説明されています（出典：Claude Code公式ドキュメント「Best practices for Claude Code」）。

非エンジニアの現場では、テストコードを書けない場合が多いはずです。その場合は、正解データを1組用意するだけで十分に機能します。

• 入力ファイルを1つコピーする（実データではなく、社外に出しても問題ない加工済みのもの）
• その入力に対する「正しい出力」を、手作業で1回作る
• この2つをフォルダに置き、「この入力を処理して、この出力と完全に一致することを確認してから完了と報告してください」と指示する

この1組があるだけで、開発の性質が変わります。人が毎回目視する必要がなくなり、AIが自分で合否を判定できるようになるからです。要件を仕様として整理する手順そのものは要件定義の進め方で詳しく扱っています。

要件を詰める質問リスト

そのまま使える質問リストを置いておきます。この10問に答えられれば、要件メモは書けます。

番号	質問	答えられないときの意味
1	この作業は今、誰が、月に何時間やっているか	効果を後から測れない。まず実測する
2	入力ファイルは誰が、どこに、いつ置くか	運用が回らない。手順から決め直す
3	出力は誰が受け取り、次に何をするか	作っても使われない可能性が高い
4	結果が間違っていたら、誰が困るか	確認の厚みを決められない
5	間違いに気づく仕組みは何か	最重要。無ければ業務に載せない
6	扱うデータに個人情報や取引条件が含まれるか	先に社内ルールとの整合を取る
7	月に何回動かすか	年1回なら、作らず手作業のほうが安い
8	使うのは何人か	2人以上なら記録の作り込みが必要
9	止まったとき、業務は何日待てるか	1日も待てないなら自社開発の対象外
10	今回作らないものは何か	範囲が無限に広がる

5番と9番が判断の分かれ目です。この2つの答え次第で、後述する判定表の結論が変わります。

工程2｜CLAUDE.mdを書く

ここが本記事で最も伝えたい工程です。CLAUDE.mdは、プロジェクトの前提を書き残しておくファイルです。これがあるかないかで、2回目以降の作業効率と、出てくるものの安定度がはっきり変わります。

CLAUDE.mdとは何か

CLAUDE.mdは、Claude Codeがすべてのセッションの冒頭で読み込むマークダウンファイルです。Anthropicの公式ドキュメントは、Claude Codeのセッションは毎回まっさらな状態から始まり、セッションをまたいで知識を引き継ぐ仕組みが2つあると説明しています。1つが利用者自身が書くCLAUDE.md、もう1つがClaudeが自分で書き溜める自動メモリです（出典：Claude Code公式ドキュメント「How Claude remembers your project」）。

重要なのは、公式ドキュメントがCLAUDE.mdを「強制される設定」ではなく「文脈」として扱うと明記している点です。書けば必ず守られる設定ファイルではありません。守らせたい動作が確実に必要な場合は、後述するフックという別の仕組みを使うよう案内されています。

それでも書く価値があるのは、人にとっての引き継ぎ資料としても機能するからです。新しく入った人がこのファイルを読めば、そのプロジェクトの決まりごとが分かる。この副次的な効果のほうが、中小企業では大きいことがあります。

置き場所は4種類

公式ドキュメントは、CLAUDE.mdの置き場所を範囲の広い順に整理しています。読み込み順もこの順です。

範囲	置き場所	用途	共有される相手
組織全体の方針	WindowsはC:\Program Files\ClaudeCode\CLAUDE.md	全社の規約・セキュリティ方針・コンプライアンス要件	組織の全利用者
利用者個人	~/.claude/CLAUDE.md	すべてのプロジェクトに共通する個人の好み	自分だけ
プロジェクト	./CLAUDE.md または ./.claude/CLAUDE.md	プロジェクト構成・規約・作業手順	チーム（バージョン管理経由）
プロジェクト内の個人	./CLAUDE.local.md	自分専用の試験データや接続先	自分だけ（gitignoreに追加する）

中小企業がまず作るべきなのは3番目、プロジェクト直下のCLAUDE.mdです。公式ドキュメントは、このファイルはバージョン管理を通じてチームで共有されるため、個人の好みではなくプロジェクト単位の基準を書くべきとしています。

なお、ゼロから書く必要はありません。プロジェクトのフォルダでClaude Codeを起動し、/init と入力すると、Claudeがコードベースを解析して、ビルドコマンドやテストの手順、見つけた規約を含んだCLAUDE.mdの原案を作ります。既にCLAUDE.mdがある場合は、上書きせずに改善案を提示する動きになります。

そのまま使える記述例

ここでは、当社が中小企業の社内ツール開発を支援するときに使っている雛形を3つ載せます。そのままコピーして、社名やフォルダ名を書き換えれば使えます。

1つ目は、最小構成です。まず何を書けばいいか分からないときは、これだけで始めてください。

# このプロジェクトについて

受注管理Excelから、協力会社への発注書PDFを作る社内ツールです。
経理課の2名が毎月20日と月末に使います。

# 作業のときの決まり

- 入力ファイルは data/input/ に置かれます。ここのファイルは絶対に上書きしないでください。
- 出力は data/output/ に、YYYYMMDD_発注書_取引先名.pdf の形式で保存してください。
- 実データを含むファイルの中身を、要約や例としてチャットに貼らないでください。
- 変更を加えたら、必ず tests/sample_input.xlsx を処理して
  tests/expected_output/ の内容と一致することを確認してから完了と報告してください。

# 決めてあること（変更しないでください）

- 金額の端数は切り捨てです。四捨五入ではありません。
- 取引先名が空欄の行は、処理せずに skipped.log に書き出してください。止めないでください。
- 同じ伝票番号が2件以上あった場合は、処理を止めて件数を報告してください。

# やらないと決めたこと

- 発注書のメール送信は行いません。PDFを作るところまでです。
- 会計ソフトへの連携は行いません。
- 単価マスタの自動更新は行いません。人が手で更新します。

2つ目は、扱うデータに注意が必要な場合です。個人情報や取引条件を含むフォルダがあるプロジェクトでは、こちらを使ってください。

# このプロジェクトについて

顧客からの問い合わせメールを分類し、担当部署ごとに一覧を作る社内ツールです。

# 触ってよい範囲

- 読み書きしてよいのは work/ 配下だけです。
- raw/ 配下は読み取りのみです。編集・移動・削除をしないでください。
- archive/ 配下には触れないでください。参照も不要です。

# データの扱い

- 顧客の氏名・メールアドレス・電話番号を、出力ファイルにそのまま書き出さないでください。
  一覧には問い合わせ番号と分類結果だけを出してください。
- 実際のメール本文を、説明や例示のために引用しないでください。
- 外部のサービスに送信する処理を追加しないでください。追加が必要だと判断した場合は、
  実装せずに理由を報告してください。

# 作業の進め方

- 3ファイル以上に変更が及ぶ場合は、先に変更計画を出して承認を待ってください。
- 削除とファイル名の変更は、実行せずに提案してください。
- 完了報告には、変更したファイルの一覧と、変更しなかったが影響を受ける可能性がある
  ファイルの一覧を必ず含めてください。

# 用語

- 「一次受け」は、当社が直接契約している顧客を指します。
- 「案件番号」は8桁で、先頭2桁が受注年度です。

3つ目は、複数人で使う場合の運用ルールを足したものです。1人で作っていたものをチームに広げるときに、この段落を追記します。

# チームでの決まり

- 作業を始める前に、必ず今日の日付でブランチを切ってください。
- コミットメッセージは日本語で、「何を」「なぜ」の順に1行で書いてください。
- 依存ライブラリを新しく追加する場合は、実装せずに名前と用途を報告してください。
  導入の可否は人が判断します。
- docs/decisions.md に、判断を1行ずつ追記してください。
  形式は「日付・決めたこと・理由・決めた人」です。

# 完了の条件

次の3つがすべて満たされたときだけ、完了と報告してください。

1. tests/ 配下のサンプルを処理し、期待結果と一致した
2. 変更したファイルの一覧を提示した
3. docs/decisions.md に今回の判断を追記した

# 困ったときの動き

- 指示が曖昧で複数の解釈ができる場合は、推測で進めずに質問してください。
- 既存の動きを変える必要が出た場合は、変更前に理由と影響範囲を報告してください。
- エラーの原因が分からない場合、エラーを握りつぶす回避策を入れないでください。

書いてはいけないこと

CLAUDE.mdは長ければよいものではありません。公式ドキュメントは1ファイルあたり200行未満を目安とし、長いファイルは文脈を消費して指示の遵守率を下げると明記しています。さらに、失敗パターンの1つとして「詳しく書きすぎたCLAUDE.md」を挙げ、長すぎると重要なルールが埋もれてClaudeが半分を無視すると説明しています（出典：Claude Code公式ドキュメント「Best practices for Claude Code」）。

公式が挙げている、書くべきものと書くべきでないものの区分は次のとおりです。

書くべきもの	書くべきでないもの
Claudeが推測できないコマンド	コードを読めば分かること
既定と異なるコードの書き方の決まり	言語の標準的な作法
テストの手順と使うテスト実行ツール	詳細なAPI仕様（リンクで足りる）
ブランチ名やPRの作法	頻繁に変わる情報
そのプロジェクト固有の設計判断	長い説明や解説
開発環境の癖（必要な環境変数など）	ファイルごとの説明の羅列
気づきにくい落とし穴	「きれいなコードを書く」のような自明の心得

判断に迷ったら、公式が示している問いが使えます。「この1行を消したら、Claudeは間違えるようになるか」。ならないなら消す、という基準です。

200行を超えたら削る

運用していると、CLAUDE.mdは必ず膨らみます。トラブルがあるたびに1行足したくなるからです。放置すると、300行のファイルができ、そして守られなくなります。

当社が勧めている運用は単純です。月に1回、CLAUDE.mdを上から読んで、3か月使っていない行を消す。これだけです。所要時間は10分です。

また、どうしても長くなる場合は、公式が用意している逃げ道が2つあります。1つは @パス の記法による別ファイルの読み込みで、最大4階層まで入れ子にできます。もう1つは、特定のファイル種別やサブフォルダで作業するときだけ読み込まれる、プロジェクトルールという仕組みです。ただし、@記法で読み込んだファイルも起動時に文脈へ入るため、単純な分割では容量の問題は解決しない点に注意してください。

なお、他のAIコーディングツールと併用していて、既にAGENTS.mdがある場合は注意が必要です。公式ドキュメントはClaude CodeはCLAUDE.mdを読み、AGENTS.mdは読まないと明記しています。両方を維持するのではなく、CLAUDE.mdの中で @AGENTS.md と書いて読み込ませるのが公式の案内です。Windowsではシンボリックリンクの作成に管理者権限か開発者モードが必要なため、この読み込み記法を使うよう案内されています。Cursorと併用している方はCursorの使い方もあわせてご確認ください。

工程3｜複数ファイルの変更

単一ファイルの修正は、指示すれば終わります。難しいのは、変更が複数のファイルにまたがるときです。ここで壊れる会社が非常に多い。

先に計画を出させる

結論から言えば、複数ファイルに及ぶ変更では、必ず先に計画を出させてから実装させます。

Claude Codeには、ファイルを読んで計画を提案するだけで、承認するまでディスクに書き込まないプランモードがあります。セッション中にShift+Tabを押すか、起動時に claude –permission-mode plan と指定すると入れます。状態表示にプランモードである旨が出ます（出典：Claude Code公式ドキュメント「Common workflows」）。

公式が推奨している流れは4段階です。調べる、計画する、実装する、記録する。そして計画が最も役に立つのは、進め方に迷いがあるとき、変更が複数ファイルに及ぶとき、変更対象のコードに不慣れなときだと明記されています。逆に、変更内容を一文で説明できる程度の小さな修正では、計画は省いてよいとも書かれています。

実務では、次のように指示すると計画の質が上がります。

変更する前に、次の3つを出してください。実装はまだしないでください。

1. 変更が必要なファイルの一覧と、それぞれ何を変えるか
2. 変更しないが影響を受ける可能性があるファイルの一覧
3. この変更で壊れる可能性がある既存の動作

そのうえで、変更を3つ以内の段階に分けて、各段階の終わりに
何を確認すれば正しいと言えるかも書いてください。

変更は小さく区切る

計画が出てきたら、一気に実装させず、段階ごとに区切って進めます。公式ドキュメントも、リファクタリングは小さく、テスト可能な単位で行うことを助言としています。

区切り方の目安は、「1段階が終わったときに、動かして確かめられること」です。3ファイルを同時に書き換えて最後にまとめて動かす、という進め方をすると、動かなかったときに原因が特定できません。

1段階ごとに次を実行してください。

1. 変更した内容の一覧を報告させる
2. 用意しておいた正解データで動かし、一致を確認する
3. 問題がなければ、その時点を保存する（バージョン管理を使っているなら、ここでコミットする）

差分を戻せる状態にする

戻せない状態で複数ファイルを触るのは、業務開発では避けてください。これはAIの問題ではなく、開発一般の原則です。

戻す手段は3段階で考えます。会社の状況に合わせてどれかを選んでください。

手段	できること	向いている会社
フォルダごとコピー	作業前の状態にまるごと戻す	社内にエンジニアが1人もいない
バージョン管理（Git）	変更を1つずつ戻す、誰が何を変えたか追う	今後も継続的に開発を続ける
作業用の複製を分ける	本番用と作業用を並行して持つ	使いながら改良を続ける必要がある

Claude Codeには、同じリポジトリの複製を作って並行してセッションを走らせる仕組み（ワークツリー）も用意されていますが、これは同時に複数の作業を進める場合の話です。まず必要なのは、失敗したときに5分で元に戻せることだけです。

途中で迷子になったとき

作業が長引くと、AIの回答が的外れになってくることがあります。公式ドキュメントは、これは文脈が埋まることによる性能低下であり、2回修正しても直らなかったら、いったん文脈を消して、学んだことを踏まえた指示を書き直すほうが速いと説明しています。

現場で使える判断基準は次の3つです。

• 同じ間違いを2回繰り返した。指示の書き直しに切り替える
• 関係ない話題を挟んだ。作業が混ざるので、区切って始め直す
• 調べさせただけで大量のファイルを読み込んだ。調査は範囲を絞るか、別の担当（サブエージェント）にやらせる

この「区切って始め直す」判断ができるかどうかで、1日の生産量が倍近く変わります。粘るより、早く諦めて指示を書き直すほうが速い、という感覚を持ってください。

工程4｜人が必ずやる確認

本記事の核です。AIに書かせたコードを業務で使うために、人が必ずやることは2つあります。動くことの確認と、壊れたときに直せる状態かの点検です。

検証できないものは出さない

まず、最も重要な原則です。Anthropicの公式ドキュメントは、よくある失敗パターンの1つとして「信じたまま検証しない」を挙げ、検証できないなら出荷するなという趣旨を明記しています（出典：Claude Code公式ドキュメント「Best practices for Claude Code」）。

さらにセキュリティのドキュメントでは、Claude Codeは与えられた権限しか持たず、提案されたコードやコマンドが安全かどうかを承認前に確認する責任は利用者にあると明記されています（出典：Claude Code公式ドキュメント「Security」）。ツールの提供元が、責任の所在をここまではっきり書いていることは重要です。

同ドキュメントによれば、Claude Codeは既定で読み取り専用の権限で動作し、ファイルの編集やテストの実行、コマンドの実行といった追加の動作が必要になると明示的に許可を求めます。また、書き込みができるのは起動したフォルダとその配下に限られ、親フォルダのファイルは明示的な許可なしには変更できません。この承認画面を「面倒だから毎回そのまま通す」運用にした時点で、この設計は無意味になります。

確認の3層構造

当社が支援するときは、確認を3層に分けています。層ごとに目的が違うので、どれかを省くと抜けが出ます。

層	何を確かめるか	やり方	省いた場合のリスク
1層目：一致	正しい答えが出るか	手作業の結果と1件ずつ突き合わせる。最低20件	間違った数字が社外に出る
2層目：例外	想定外の入力で正しく振る舞うか	工程1で洗い出した例外を、わざと入力して試す	月末の繁忙日に止まる
3層目：保守	壊れたときに直せる状態か	後述の点検リストで確認する	半年後に誰も触れなくなる

1層目の「最低20件」に根拠はありませんが、経験上、10件だと偶然一致することがあり、50件だと現場が続きません。20件は、現実的に回せて、かつ偶然では通らない件数です。

2層目で見落とされがちなのが、「止まってほしい場面で止まるか」の確認です。エラーを握りつぶして黙って処理を続けるコードは、動いているように見えるので最も危険です。工程2のCLAUDE.md記述例に「エラーを握りつぶす回避策を入れないでください」と書いたのは、このためです。

壊れたとき直せるかの点検

3層目の点検リストです。この6項目すべてに「はい」と答えられないものは、業務に載せないでください。

1. このツールが何をするものか、作った人以外が読んで分かる文書があるか
2. 同じものをもう一度作り直せる指示文が保存されているか
3. 入力ファイルが変わったとき、どこを直せばいいかが分かるか
4. 止まったときのエラーが、画面かログに日本語で残るか
5. 1つ前の状態に戻す手段があるか
6. 作った人が来週から1か月休んでも、業務が回るか

6番が本質です。「作った人が休んでも回るか」に「いいえ」なら、それはまだ開発が終わっていません。コードは完成していても、業務としては未完成です。

レビューをAIに任せる範囲

確認作業の一部は、AIに任せられます。公式ドキュメントは、作業が終わったと判断する前に、まっさらな文脈のサブエージェントに差分をレビューさせ、抜けを報告させる方法を推奨しています。理由は、実装した本人の思考過程を知らない状態で見るため、結果そのものを評価できるからです。

同時に、注意点も明記されています。抜けを探すよう指示されたレビュー役は、問題がなくても何かしら報告してくるため、指摘をすべて追いかけると過剰な作り込みにつながる、というものです。対策として、正しさや要件に関わる指摘だけを挙げるよう指示し、それ以外は任意扱いにすることが案内されています。

Claude Codeには、現在の差分を別の文脈で確認する /code-review や、自分が変更したコードの脆弱性を確認させる /security-review が用意されています。また、GitHubを使っている場合は、プルリクエストやIssueのコメントで@claudeとメンションすると、Claudeがコードを解析して変更を提案する仕組みも提供されています（出典：Claude Code公式ドキュメント「Claude Code GitHub Actions」）。

ただし、これらはすべて一次抽出です。業務仕様と合っているかの最終判断は、業務を知っている人にしかできません。この線引きの詳細はAIコードレビューの使い方にまとめています。

工程5｜設計と判断を残す

コードは残ります。しかし「なぜそう作ったか」は残りません。そして、半年後に必要になるのは後者です。

残すのは4点セット

当社が必ず作ってもらっているのは、次の4つです。CLAUDE.mdと同じフォルダに置きます。

残すもの	中身	誰のためか
要件メモ	工程1で決めた入力・出力・例外・受入条件・作らないもの	次に直す人
CLAUDE.md	プロジェクトの前提と決まりごと	AIと、次に触る人
判断の記録	日付・決めたこと・理由・決めた人を1行ずつ	半年後の自分
確認の記録	いつ何件を手作業と突き合わせ、結果がどうだったか	結果を疑われたときの説明用

作成には時間をかけないでください。4点合わせてA4で3枚以内が目安です。それ以上書くと、更新されなくなり、更新されない文書は嘘になります。

下書きはAIに作らせて構いません。次のように指示すると、そのまま使える粒度で出てきます。

今回作ったツールについて、引き継ぎ資料を作ってください。
読む相手は、プログラミングの知識がない経理担当者です。

次の4つに分けて、全体でA4で3枚以内にしてください。

1. 何をするものか（動かし方と、出てくるもの）
2. 前提と制約（扱えないデータ、対応しないと決めたこと）
3. 今回の判断とその理由（なぜその方式にしたか）
4. 困ったときの対処（よくあるエラーと、その意味）

専門用語を使う場合は、初出のときに1行で説明を付けてください。

決めた理由を1行残す

4点セットの中で、かける手間に対して最も効いてくるのが判断の記録です。1行で構いません。

実際の書き方の例を示します。

2026-08-05 端数は切り捨てにした 経理課の既存運用に合わせるため 田中
2026-08-07 伝票番号の重複は処理を止める 過去に二重計上の事故があったため 田中
2026-08-12 メール送信は実装しない 誤送信のリスクを避けるため 山田課長
2026-08-20 単価マスタは手動更新のまま 更新頻度が年2回で自動化の必要が薄いため 田中

この4行があるだけで、半年後の会話が変わります。「なぜ切り捨てなんですか」に即答できる状態は、想像以上に効きます。逆にこれが無いと、当時の判断を再検討するところから始まり、同じ議論を最初からやり直すことになります。

引き継ぎの現実的なやり方

文書を作っただけでは引き継ぎになりません。中小企業で現実的に機能するのは、次の3ステップです。

1. 受け取る人の前で1回動かす。画面を見せながら、入力から出力までを通す。30分
2. 受け取る人に1回動かしてもらう。作った人は口を出さず、詰まった箇所をメモする。30分
3. 詰まった箇所を文書に追記する。ここが最も価値のある更新になる。30分

合計1時間半です。2番で詰まった箇所こそが、文書に書かれていなかった暗黙の前提です。作った人には見えない部分なので、他人にやってもらう以外に見つける方法がありません。

担当は「作った人」ではなく「その業務を持っている人」にしてください。作った人が異動しても、業務は残るためです。

工程6｜運用に乗せる

最後の工程です。ここまで来て失敗するのは、決めるべきことを決めていない場合だけです。

動かす人と直す人を決める

運用開始前に、名前を書いて決めるのは3つです。

役割	やること	誰がやるか
動かす人	決まった日に実行し、出力を確認する	その業務の担当者
直す人	止まったとき、変更が必要なときに手を入れる	Claude Codeを扱える人（社内か外部）
決める人	仕様変更の可否と、やめる判断をする	その業務の責任者

「直す人」が空欄のまま運用を始めないでください。空欄のまま始めた場合、実質的に「作った人が永久に面倒を見る」という運用になります。作った人が別部署に異動した瞬間に、この仕組みは止まります。

止まったときの手順

止まる前提で手順を決めておきます。紙1枚で足ります。

1. 止まったら、その日の業務は手作業で回す（手作業の手順を消さない）
2. エラーの画面を撮り、いつ・何を入力したかと一緒に「直す人」に渡す
3. 直す人は、直す前に1つ前の状態に戻せることを確認してから着手する
4. 直したら、正解データで動かして一致を確認してから運用に戻す
5. 判断の記録に、何が起きて何を直したかを1行足す

1番が最も重要です。自動化したからといって、手作業の手順書を捨ててはいけません。止まったときの逃げ道が無くなり、業務そのものが止まります。

変更を続けるための場所

業務は変わるので、ツールも変わります。変更を続けるために必要なのは、次の2つだけです。

• 置き場所を1つに決める。個人のパソコンのデスクトップに置かない。共有フォルダかバージョン管理に置く
• 変更のタイミングを決める。思いついたときに直すのではなく、月次で見直す日を決める

また、必ず守らせたい動作がある場合は、CLAUDE.mdへの記述では不十分です。公式ドキュメントは、CLAUDE.mdはあくまで文脈であり、確実に動作を制御したい場合はフックという仕組みを使うよう案内しています。フックはClaude Codeの動作の節目で自動的に実行されるコマンドで、AIの判断に頼らず、決まった動作を必ず行わせるものです（出典：Claude Code公式ドキュメント「Automate actions with hooks」）。特定のファイルへの編集を禁止する、編集後に必ず整形をかける、といった用途に向きます。

外部のサービスやデータベースとつなぐ必要が出てきた場合の設定はClaude MCP設定の手順にまとめています。

自社で作る／外に出す判定表

ここが、この記事で最も判断に使える部分だと考えています。Claude Codeがあっても、自社で作るべきでないものは存在します。

判定の軸は5つ

判断の軸は、技術の難易度ではありません。壊れたときに何が起きるかです。次の5つで見ます。

1. 停止許容時間：止まったとき、業務は何日待てるか
2. 誤りの取り返しやすさ：間違った結果が出たとき、後から直せるか
3. 扱うデータ：個人情報・取引条件・金銭が含まれるか
4. 使う人の広がり：作った本人だけか、部署か、社外に届くか
5. 直せる人の有無：社内に、直せる人が2人以上いるか

判定表

5つの軸で、自社で作るか外に出すかを整理します。1つでも「外に出す」に該当したら、外に出す側で検討してください。

軸	自社で作ってよい	外に出す（または作らない）
停止許容時間	数日止まっても手作業で回せる	1日でも止まると業務が止まる
誤りの取り返し	出力を人が見てから使う。間違えても直せる	そのまま社外に出る。取引や請求に直結する
扱うデータ	社内の集計データ、加工済みの資料	個人情報、与信・単価などの取引条件、決済情報
使う人の広がり	作った本人と、同じ課の数名まで	他部署や社外の人が使う。顧客が触る
直せる人	社内に2人以上いる	作った1人しかいない、または0人
変更の頻度	年に数回。自分たちの都合で決められる	法改正や取引先の様式変更に追随が必要
接続先	手元のファイルだけを扱う	基幹システムや会計ソフトに書き込む
可用性の要求	担当者が動かしたときだけ動けばよい	24時間動き続ける必要がある

この表を作るときに意識したのは、「難しいから外注」という基準を使わないことです。技術的な難しさは、Claude Codeがかなりの部分を引き受けます。残るのは責任の重さであり、そこは道具では軽くなりません。

迷ったときの決め方

表を見ても迷う場合は、次の質問に答えてください。

「この仕組みが間違った結果を出し、それが3か月間気づかれなかったら、何が起きますか」

答えが「集計をやり直せばよい」なら自社で作ってよい範囲です。答えが「取引先に謝罪して差額を精算する」「監査で指摘される」なら、外に出す側です。

もう1つ、現実的な逃げ道があります。自社で試作を作ってから外注するという進め方です。動く試作が1つあると、要望が具体的になり、外注先との認識のずれが小さくなります。この方法の詳細はAIでアプリを作るで扱っています。

外注との違いと契約の考え方

「Claude Codeがあれば開発会社は要らない」とは書きません。外注が持っていて、自社にないものが確実にあるからです。

外注が持っているもの

開発会社に発注したときに買っているのは、コードを書く時間だけではありません。

外注が持っているもの	自社で内製した場合
納品物に対する責任	誰も責任を負わない。動かなくても自己責任
担当者が辞めても続く体制	担当1名が辞めると止まる
他社での失敗の蓄積	自社で1回ずつ失敗して学ぶ
非機能要件の設計（性能・可用性・セキュリティ）	意識に上がらないまま抜ける
保守の窓口と対応時間の約束	担当者が休みなら止まったまま
他システムとの接続の知見	接続先の仕様に振り回される

特に4番目と5番目は、内製でほぼ確実に抜けます。動くものは作れるが、負荷がかかったとき、深夜に止まったとき、担当が休んでいるときの設計が無い。これは能力の問題ではなく、経験していないと気づけない領域です。

一方で、外注に出さなくてよいものもはっきりしています。月に数回動かす社内向けの集計、フォーマット変換、書類の下書き作成といった、止まっても手作業に戻れる範囲です。ここを外注すると、見積と発注と検収の手間のほうが大きくなります。

準委任と請負の選び方

外注する場合、契約の形が結果を左右します。IPAは、情報システム開発におけるユーザー企業とITベンダー間の取引を透明化するため、「情報システム・モデル取引・契約書」を公開しており、各開発段階で双方が担うべき責務の解説と契約書のひな型を提供しています。第二版に加えて、アジャイル開発版も用意されています（出典：IPA「情報システム・モデル取引・契約書」）。

中小企業が押さえるべき違いは次のとおりです。

観点	請負	準委任
約束するもの	成果物の完成	作業の遂行
向いている場面	作るものが確定している	作りながら決めていく
要件が変わったとき	変更契約と追加費用が発生する	優先順位の入れ替えで対応しやすい
発注側の関与	少なくてよい	継続的に判断する必要がある
ありがちな失敗	要件が固まらないまま請負にして揉める	丸投げして何もできあがらない

契約形態の詳細と、偽装請負にならないための注意点は準委任と請負の違いで解説しています。

ここでClaude Codeが効いてきます。自社で試作を作っていると、要件が固まるため請負契約を選びやすくなります。逆に、要件が曖昧なまま請負で発注すると、変更のたびに追加費用の交渉が発生します。試作は、契約形態を有利に選ぶための道具でもあります。

契約前に決める5項目

発注前に、次の5つを書面で決めてください。

1. 成果物の受入条件：何が動けば検収するか。工程1の受入条件がそのまま使える
2. ソースコードの扱い：納品されるか、著作権は誰に帰属するか、他社に保守を頼めるか
3. AI利用の可否と申告：ベンダー側がAIでコードを生成することを認めるか、その場合の品質保証の扱い
4. 保守の範囲と応答時間：何時間以内に一次回答が来るか、対応時間帯はいつか
5. 引き継ぎ時の提供物：契約終了時に何を渡してもらえるか（設計書、環境構築手順、判断の経緯）

3番目は、2026年時点では必ず確認してください。ベンダー側がAIを使うこと自体は問題ではありません。問題は、使ったことを申告せず、品質保証の考え方が曖昧なまま納品されることです。発注側が自社でClaude Codeを触っていると、この質問を具体的にできるようになります。これも内製経験の副次的な価値です。

やめ時の判断と撤退の手順

正直に書きます。自社で抱えきれなくなる状況は、確実に来ます。来ることを前提に、条件を先に決めておいてください。

抱えきれなくなる5条件

次のうち2つ以上に当てはまったら、自社開発を続ける判断を見直す時期です。

条件	具体的な兆候	取るべき行動
直せる人が1人になった	その人が休むと誰も触れない	外部の保守先を確保する
修正に毎回1時間以上かかる	小さな変更のはずが半日消える	作り直すか、外注に切り替える
使う人が部署を越えて増えた	頼んでいない部署から問い合わせが来る	いったん止めて、正式なものとして作り直す
止まると業務が止まるようになった	手作業の手順を誰も覚えていない	外注に移すか、手作業の手順を復活させる
扱うデータが重くなった	個人情報や取引条件が入り込んできた	即座に止めて、扱いを設計し直す

3番目の「使う人が部署を越えて増えた」は、良い兆候に見えるので見逃されます。しかし、これは自社で作ってよい範囲を出た合図です。便利だから広がったのであれば、正式なものとして作り直す価値があるという意味でもあります。

やめ方の手順

やめると決めたら、次の順で進めます。捨て方を決めておかないと、動かないものが社内に残り続けます。

1. 手作業の手順を先に復活させる。1回通しで実行して、回ることを確認する
2. 停止日を決めて周知する。使っている人全員に、いつから使えなくなるかを伝える
3. 4点セットは残す。要件メモ・CLAUDE.md・判断の記録・確認の記録は捨てない
4. 実データは削除する。作業用にコピーしたファイルが残っていないか確認する
5. 外注に移す場合は、4点セットをそのまま渡す。見積の精度が上がる

3番目が肝です。仕組みを捨てても、記録が残っていれば投資は無駄になりません。その業務が何をしていたかの記録は、次に作るときの出発点になり、外注に出すときの要件そのものになります。やめることは失敗ではありません。

モデルケース｜社内ツール開発

ここから、6工程を通した具体例を示します。これは実在企業の実績ではなく、当社の支援内容をもとに構成したモデルケース（試算）です。数値は下記の前提で計算した試算値であり、同じ結果を保証するものではありません。

前提条件

項目	設定
会社	住宅設備の工事会社B社（従業員35名・地方都市）
対象部署	工務課3名、経理課2名
作るもの	受注管理Excelから協力会社向け発注書を作り、原価を集計する社内ツール
担当者	工務課の主任1名（プログラミング未経験、Excel関数は使える）
時給換算	2,500円（社会保険料等を含む会社負担ベース）
営業日	月20営業日
利用ツール	Claude Pro（1名分）

Claude Codeの利用にあたっては、Anthropicの公式ページがClaude Codeはすべての有料プランに含まれ、ウェブ・デスクトップ・モバイル・Claude Codeの利用量が同じ枠から消費されると案内しています。Proは年払いで月17ドル（200ドルを前払い）、月払いで月20ドル、Maxは月100ドルからです。チームで使う場合のTeamプランは、標準シートが年払いで1名あたり月20ドル（月払いは25ドル）、上位のプレミアムシートが年払いで1名あたり月100ドル（月払いは125ドル）と表示されています（出典：Anthropic「Plans & Pricing」）。

6工程にかかった時間

担当者1名が、通常業務の合間に進めた場合の試算です。

工程	実作業時間	金額換算	備考
1．要件を詰める	6時間	15,000円	経理課との擦り合わせに3時間
2．CLAUDE.mdを書く	2時間	5,000円	/initの出力を土台に手直し
3．作る	10時間	25,000円	3回に分けて実装
4．確認する	12時間	30,000円	過去3か月分の実績と突き合わせ
5．設計を残す	3時間	7,500円	下書きはAI、確認と修正が人
6．運用に乗せる	3時間	7,500円	引き継ぎ1.5時間を含む
合計	36時間	90,000円	実質3週間

注目してほしいのは、作る工程（10時間）より確認する工程（12時間）のほうが長い点です。これは異常ではなく、業務に載せるものを開発するときの標準的な比率です。ここを短縮しようとすると、後で必ず戻ってきます。

削減時間の試算

導入後、月あたりの作業時間の変化を試算します。

業務	導入前（月）	導入後（月）	削減時間	月間削減額
発注書の作成	32時間	8時間	24時間	60,000円
原価の集計	18時間	5時間	13時間	32,500円
請求前の突合	10時間	4時間	6時間	15,000円
合計	60時間	17時間	43時間	107,500円

導入後にゼロにならないのは、出力の確認を人が続けているからです。発注書の8時間は、内容を目視で確認して承認する時間です。ここをゼロにすると、工程4で作った確認の仕組みが意味を失います。

運用に伴って継続的にかかる時間もあります。月次の見直しに1時間、様式変更などへの対応が平均1時間、合わせて月2時間（5,000円相当）です。ツール費用はClaude Proの1名分です。

つまずいた3点

このモデルケースで、実際に起きやすいつまずきを3つ挙げます。

1つ目は、要件が固まる前に作り始めたこと。最初の2日間、「とりあえず動かしてみる」で進めた結果、経理課が求める原価の区分と、工務課が使っている区分が違うことが後から判明しました。工程1に戻って6時間かけ直しています。要件を先に詰めていれば、この6時間は不要でした。

2つ目は、確認を20件で止めたこと。20件では通ったのに、実際の月次処理で1件だけ結果が合わない事象が出ました。原因は、値引き行が入った伝票の扱いでした。20件のサンプルに値引き行が含まれていなかったのです。以降は、「珍しいパターンを意図的に含めた20件」を作るようにしています。件数より、含まれる種類のほうが重要でした。

3つ目は、CLAUDE.mdが3か月で210行に膨らんだこと。不具合が出るたびに1行足していった結果です。Claudeが以前は守っていた指示を守らなくなり、調べたところ、公式ドキュメントの200行の目安を超えていました。使っていない行を削って120行に戻したところ、挙動が安定しています。

開発でよくある失敗5つ

支援の現場で繰り返し見る失敗を、対策とセットで挙げます。

失敗1：本番データで作り始める。試している最中に、元のファイルを上書きしてしまう事故が起きます。対策は単純で、作業用のコピーだけを置いたフォルダでClaude Codeを起動することです。公式ドキュメントによれば、Claude Codeが書き込めるのは起動したフォルダとその配下に限られるため、この起動位置を守るだけで被害範囲が限定されます（出典：Claude Code公式ドキュメント「Security」）。

失敗2：承認画面を全部そのまま通す。最初は1つずつ読んでいたのに、数日で「はい」を押すだけになります。対策は、削除とファイル名の変更だけは必ず読むと決めることです。全部を丁寧に読むルールは続きません。読む対象を絞ってください。

失敗3：うまくいった指示を残さない。同じ作業を翌月にやろうとして、指示文が思い出せず、また試行錯誤することになります。対策は、うまくいった指示文をCLAUDE.mdと同じフォルダのテキストファイルに貼っておくことです。工程5の4点セットの一部として扱ってください。

失敗4：1人で完結させる。作った本人しか使い方を知らない状態で運用が始まります。3か月後に異動が出て止まります。対策は、工程5の引き継ぎ手順、特に「受け取る人に1回動かしてもらう」を必ず実施することです。

失敗5：効果を測らずに広げる。削減時間を測らないまま次のツールを作り始めると、どれが効いているか分からなくなります。対策は、工程1の質問リスト1番、導入前に現在の作業時間を実測しておくことです。後からは測れません。

国内データで見る現在地

自社の状況が特殊なのか一般的なのかを判断するために、公的な調査結果を見ておきます。

IPAが2026年7月30日に公開した「DX動向2026」によると、DXを推進する人材の「量」について「やや不足している」「大幅に不足している」と回答した企業の合計は2025年度で85.5%にのぼります。ただし「大幅に不足している」は50.1%で、2023年度の62.1%、2024年度の58.5%と比べるとやや解消の傾向が見られます。人材の「質」については、2024年度の86.1%から2025年度は88.8%とやや増加しています（出典：IPA「DX動向2026」）。

従業員規模別に見ると、量の不足感は301人以上の企業で9割を超え、100人以下の企業でも6割を超えています。中小企業でも、6割以上が人材不足を感じているということです。

AIの導入・運用上の課題としては、「専門人材が不足している」が50.1%と最も高く、次いで「生成AIの効果やリスクに関する理解が不足している」が45.8%、「適切な利用を管理するためのルールや基準の作成が難しい」が39.7%となっています（出典：IPA「DX動向2026」広がるAI導入、DXは変われるか）。

用途別の効果に関しては、興味深い結果が出ています。「データ分析・予測・インサイト抽出」および「プログラムコードやシステム開発支援」は効果が出ている割合が高い一方で、ともに「効果が出ていない」も3割弱あるとされています。同じ用途でも、成果が出る会社と出ない会社に分かれるということです。

本記事の6工程は、この差を埋めるためのものだと考えてください。効果が出ない3割の多くは、工程3だけをやって工程1・4・5・6を飛ばしているというのが、当社が現場で見ている実感です。

なお、業種別に見ると「プログラムコードやシステム開発支援」の用途では情報通信業が76.3%と他業種を大きく上回っており、開発を本業とする業界で先行している状況です。製造業や建設業、サービス業がこれから追いかける段階にある、という位置づけになります。

セキュリティ面の前提も確認しておいてください。IPAの「情報セキュリティ10大脅威 2026」では、組織向けの脅威が公表されています（出典：IPA「情報セキュリティ10大脅威 2026」）。社内で開発したツールも、扱うデータがある以上は同じ土俵の上にあります。

よくある質問（FAQ）

Q. プログラミングの知識は必要ですか

コードを書く知識は不要ですが、出てきた結果が正しいかを判断する業務知識は必須です。工程4の確認は業務を知っている人にしかできません。逆に言えば、業務を知っている人であれば、コードが読めなくても開発を進められます。

Q. CLAUDE.mdは必ず必要ですか

1回で終わる作業なら不要です。2回目以降のセッションがある場合は、あったほうが確実に楽になります。公式ドキュメントも、同じ訂正を2回入力したときが書き足すタイミングだとしています。まずは20行程度から始めてください。

Q. CLAUDE.mdに書けば必ず守られますか

守られるとは限りません。公式ドキュメントは、CLAUDE.mdを強制される設定ではなく文脈として扱うと明記しています。確実に止めたい動作がある場合は、フックという別の仕組みを使うよう案内されています（出典：Claude Code公式ドキュメント「How Claude remembers your project」）。具体的で簡潔に書くほど、守られる確率は上がります。

Q. 複数ファイルの変更で毎回壊れます

先に計画を出させていない可能性が高いです。プランモードで計画を作らせ、承認してから実装させてください。公式ドキュメントも、変更が複数ファイルに及ぶ場合は計画が最も役に立つとしています。あわせて、3ファイル以上の変更では計画を先に出すルールをCLAUDE.mdに書いておくと安定します。

Q. 確認はどこまでやれば十分ですか

本記事の3層（一致・例外・保守）をすべて通すことが最低ラインです。特に3層目、作った人が1か月休んでも業務が回るかの点検を省かないでください。ここを省くと、コードは完成していても業務としては未完成のまま運用が始まります。

Q. AIが書いたコードの品質は信用できますか

品質を信用するのではなく、検証する仕組みを持つと考えてください。公式ドキュメントは、検証できないなら出荷するなという趣旨を明記しており、提案されたコードの安全性を承認前に確認する責任は利用者にあるとしています。正解データ1組を用意することが、最も現実的な検証手段です。

Q. 社内に詳しい人が1人しかいません

その状態で業務に載せるのは危険です。判定表の「直せる人」の軸で「外に出す」側に該当します。対策は2つ、もう1人育てるか、外部の保守先を確保するかです。どちらもできない場合は、止まっても手作業に戻れる範囲に用途を限定してください。

Q. 開発会社に頼まなくてよくなりますか

なりません。外注は、納品物への責任、担当が辞めても続く体制、性能や可用性の設計、保守の窓口といったものを提供しています。Claude Codeが置き換えるのは「作る時間」であって、これらではありません。自社で持つべきものと外に出すべきものを、判定表で分けてください。

Q. 外注する場合、契約はどう選びますか

作るものが確定していれば請負、作りながら決めるなら準委任が基本です。IPAが「情報システム・モデル取引・契約書」として、第二版とアジャイル開発版のひな型を公開しています（出典：IPA「情報システム・モデル取引・契約書」）。自社で試作を作ってから発注すると要件が固まり、請負を選びやすくなります。

Q. 費用はどれくらいかかりますか

ツール費用としては、Anthropicの公式ページによればClaude Codeはすべての有料プランに含まれ、Proは年払いで月17ドル（200ドルを前払い）、月払いで月20ドル、Maxは月100ドルからです。Teamプランは標準シートが年払いで1名あたり月20ドル、プレミアムシートが年払いで1名あたり月100ドルと表示されています（出典：Anthropic「Plans & Pricing」）。大きいのはツール費用ではなく、工程1・4・5・6にかかる社内の人件費です。モデルケースでは36時間、90,000円相当と試算しました。

Q. どのプランを選べばよいですか

まず1名がProで始め、使用量の上限に当たるようになってから見直すのが現実的です。公式ページは、利用量の上限が5時間単位で更新され、有料プランには週単位の上限も加わること、ウェブ・デスクトップ・モバイル・Claude Codeの利用が同じ枠から消費されることを案内しています。重い作業が続く場合は、Consoleアカウント経由の従量課金に切り替える選択肢も示されています（出典：Anthropic「Plans & Pricing」）。

Q. 動作環境の条件はありますか

公式ドキュメントによれば、macOS 13.0以降、Windows 10（1809以降）またはWindows Server 2019以降、Ubuntu 20.04以降、Debian 10以降、Alpine Linux 3.19以降に対応し、メモリは4GB以上、インターネット接続が必要です。Windowsでも管理者権限なしで導入できますと案内されています（出典：Claude Code公式ドキュメント「Advanced setup」）。

Q. 作ったものを他部署に配ってよいですか

配る前に、判定表をもう一度通してください。使う人が部署を越えた時点で、自社で作ってよい範囲を出ている可能性があります。広がったこと自体は、そのツールに価値があった証拠です。正式なものとして作り直すか、外注に移すかを検討する合図だと捉えてください。

Q. 途中でやめる判断はどう下しますか

本記事の5条件のうち2つ以上に当てはまったときです。特に、直せる人が1人になった場合と、修正に毎回1時間以上かかるようになった場合は要注意です。やめるときも、要件メモ・CLAUDE.md・判断の記録・確認の記録の4点は残してください。外注に出すときの要件そのものになります。

Q. 何から始めればよいですか

いま手作業でやっている業務を1つ選び、工程1の質問リスト10問に答えるところからです。10問に答えられなければ、まだ作る段階ではありません。特に1番（現在の作業時間）と5番（間違いに気づく仕組み）は、作り始める前に必ず埋めてください。

まとめ｜開発は残す仕事

最後に、要点を整理します。

• Claude Codeの開発で難しいのはコードを書くことではなく、検証・保守・引き継ぎを残すこと
• 業務投入までは6工程。AIが主役なのは工程3だけで、残り5つは人の仕事
• 工程1で入力・出力・例外・受入条件を決める。特に例外の扱いを明文化する
• CLAUDE.mdはプロジェクト直下に置き、200行未満を保つ。/initで原案を作れる
• 複数ファイルの変更は、必ず計画を先に出させ、小さく区切って進める
• 公式ドキュメントは「検証できないなら出荷するな」「承認前の確認は利用者の責任」と明記している
• 確認は一致・例外・保守の3層。作った人が1か月休んでも回るかを点検する
• 残すのは要件メモ・CLAUDE.md・判断の記録・確認の記録の4点セット
• 自社で作るか外に出すかは、技術の難易度ではなく壊れたときの影響で決める
• 外注は責任・体制・非機能設計・保守窓口を提供している。置き換わるのは作る時間だけ
• 抱えきれなくなる条件を先に決め、やめるときも記録は残す

Claude Codeを使うと、作る速度は確かに上がります。しかし、上がるのは作る速度だけです。確認する時間、記録を残す時間、引き継ぐ時間は、これまでと同じだけかかります。むしろ作る速度が上がった分、これらが全体に占める割合は増えます。

この記事の6工程は、その増えた部分を落とさずに回すための手順です。まずは工程1の質問リスト10問を、いま困っている業務1つについて埋めてみてください。10問埋まった時点で、自社で作るべきか外に出すべきかは、ほぼ見えているはずです。