AIコーディングの本番運用｜Claude Codeと外注の判断

試作では動くのに、本番で止まるのはなぜか

試作は、作った本人の端末で、少ないデータを使い、うまくいく手順だけを通せば完成したように見えます。本番では、ほかの社員が使い、件数が増え、想定していない入力や外部サービスの停止も起きます。APIキーがコードに直接書かれていた、誰でも画面を開けた、エラーが起きても誰も気づかなかった。こうした問題は、試作の段階ではほとんど表に出ません。

IPAの『DX動向2026』では、「AIや生成AI独自のリスクマネジメントを実施している」企業は14.2%にとどまっており、ハルシネーションや学習データの情報漏洩といったリスクへの対策が追いついていないと報告されています（出典：IPA『DX動向2026』）。AIが書いたコードを本番で動かす場合も同じで、試作の段階では考えずに済んだ備えが必要になります。試作で動いたことと、本番で使い続けられることは、分けて確かめる必要があります。

Claude Codeに任せやすい作業、任せきれない作業

Claude Codeは、コードを読んで直す場所を探す、テストを書く、決まった形の機能を作るといった作業を速く進められます。一方で、何を作るかを決めることや、本番に出してよいかの判断は人に残ります。公式のドキュメントでも、提案されたコードとコマンドの安全性を承認の前に確かめるのは利用者の責任だと書かれています（出典：Claude Code 公式ドキュメント「セキュリティ」）。

本番運用までに必要な作業の全体像

本番運用に必要な作業は、コードを書くことのほかに、大きく6つの段階に分かれます。この記事では次の順に説明します。

よくあるつまずきと、先に打てる手

本番運用でよく起きるつまずきは、ある程度決まっています。作り始める前に、次の表で自社の状況を確かめておきましょう。

Claude Codeとは

Claude Codeは、Anthropic社が提供するAIのコーディングツールです。日本語で指示を出すと、ファイルを読み、プログラムを書き、動かして確かめるところまでをAIが進めます。業務の自動化の仕組みや社内ツール、外部サービスとの連携などを、これまでより短い時間で作れるのが特長です（参考：Claude Code 公式ドキュメント）。

社員が自分の業務でClaude Codeを使う方法は Claude Codeは非エンジニアでも使える｜業務別の例と始め方 で解説しています。本記事は、Claude Codeで作った仕組みを本番で運用する方法と、その開発を外部に頼むときの判断に絞って説明します。

外注で頼める範囲

Claude Code開発の外注とは、Claude Codeを使いこなす外部の会社や個人に、業務の仕組みづくりを依頼することです。頼める範囲は、どの業務を対象にするかの整理から、仕組みの設計、構築、テスト、運用ルールづくり、稼働後の保守までと幅広く、どこまで任せるかは発注する側が決められます。

「Claude Code 構築代行」「Claude Code 受託開発」「Claude Code 開発代行」など、呼び方は会社によってさまざまです。呼び方よりも、どの工程を任せ、何が手元に残るのかを確かめることが大切です。

従来の開発外注との違い

Claude Codeを使った開発でも、要件を決め、作り、確かめるという流れは従来の受託開発と変わりません。違いが出やすいのは、次の3つです。

作る時間が短くなる分、費用も下がりやすくなります。ただし、AIが書いたコードを人が確かめる手間はなくなりません。速く作れるかどうかより、作ったものを確かめて直し続けられる形で納めてくれるかが大切です。

導入支援・研修との違い

Claude Codeの外部サービスには、開発の外注のほかに、社員が使えるようにする研修や、社内に広げるための導入支援もあります。開発の外注は「動く仕組みを作ってもらう」こと、研修や導入支援は「社員が使える状態をつくる」ことが目的です。研修・伴走・内製化支援など支援の形の違いは Claude Code 導入支援とは で詳しく比べています。

本番で使うなら決めておきたいプランと権限モード

会社で本番の開発に使うなら、最初にプランと権限の設定を決めます。Claude Codeは法人向けのTeamプランとEnterpriseプランに含まれています（出典：Claude 公式の料金ページ）。TeamプランやEnterpriseプラン、APIなどの商用の条件では、Claude Codeに送ったコードやプロンプトは生成モデルの学習に使われません（詳しくはセキュリティの章で説明します）。

権限モードは、Claude Codeが確認なしに実行できる操作を決める設定です。公式のドキュメントによると、Manualモードでは読み取り専用の権限で始まり、ファイルの編集やコマンドの実行の前に利用者へ確認を求めます。autoモードでは、別のモデルが操作を確かめ、安全でないと判断したものを止めます。組織の側でautoモードをオフにすることもできます（出典：Claude Code 公式ドキュメント「セキュリティ」）。権限の設定はバージョン管理に入れてチームに配れるため、本番の開発では個人の判断に任せず、組織で決めた設定を使うのが基本です（出典：Claude Code 公式ドキュメント「権限を設定する」）。

ほかのAIコーディングツールとの違い

AIコーディングのツールは、大きく2つに分けられます。エディタの中でコードの続きを提案する補完型と、Claude Codeのように指示を受けてファイルを読み、コードを書き、コマンドを実行して確かめるところまで進めるエージェント型です。

エージェント型は任せられる範囲が広い分、どこまでの操作を許すか、誰が変更を読むかによって、本番運用での安全性が大きく変わります。ツールを選ぶときは、機能の多さよりも、自社の権限の管理、データの扱い、レビューの流れに組み込めるかを確かめましょう。

作り始める前に、要件と仕様を文章にする

AIは、指示があいまいなところを、それらしい形で埋めてしまいます。人なら聞き返す点も、そのまま作り進めることがあるため、作り始める前に要件と仕様を文章にしておくことが大切です。最低限、次の点を書いておきましょう。

Claude Codeには、編集を始める前にコードを調べて進め方を示させ、承認してから実装に進むplanモードもあります。大きな変更のときは、まず計画を読み、仕様とずれていないかを確かめてから作らせると、手戻りを減らせます（出典：Claude Code 公式ドキュメント「コストを効果的に管理する」）。

CLAUDE.mdにプロジェクトの決まりを書いておく

CLAUDE.mdは、ビルドやテストのコマンド、コーディングの決まり、設計の判断などを書いておくファイルです。Claude Codeは毎回のセッションの始めにこれを読みます。リポジトリの直下に置けばバージョン管理を通じてチームで共有でき、/initコマンドで最初のひな形を作れます。公式は、1つのファイルを200行以下に収めることを目安にしています（出典：Claude Code 公式ドキュメント「Claude があなたのプロジェクトを記憶する方法」）。

書き方のこつは、確かめられるほど具体的に書くことです。「変更をテストする」ではなく「コミットの前に決まったテストのコマンドを実行する」のように書くと、守られやすくなります。

ただし、CLAUDE.mdは指示として読まれるもので、守ることを強制する仕組みではありません。公式のドキュメントも、操作を確実に止めたいときは権限の拒否ルールやフックを使うよう案内しています。守ってほしい決まりはCLAUDE.mdに書き、必ず止めたい操作は権限の設定で止める、と分けておくことが大切です。

テストとコードレビューを毎回の流れに入れる

Claude Codeが書いたコードも、人が差分を読み、テストを通してから取り込むのが前提です。テストに加えて、コードの書き方の誤りを機械で見つける静的解析（lint）や型のチェックを、決まった手順で毎回走らせると、見落としが減ります。

テストは、すべてを一度にそろえようとせず、業務で止まると困る流れから順に足していきます。テストを書く作業そのものはClaude Codeに任せやすいため、人は「そのテストが業務の条件を正しく表しているか」を確かめることに時間を使いましょう。テストが通っても、業務の要件を満たしているとは限らない点にも注意が必要です。

CI/CDで、テストと反映の手順を自動にする

変更を取り込むたびにテストを自動で走らせる仕組みをCI、決まった手順で本番に反映する仕組みをCDと呼びます。手作業での反映は、手順の抜けや、確かめていない変更が混ざる原因になるため、本番運用では早めに整えておきたい部分です。

Claude Codeは、GitHub Actionsのワークフローの中でも動かせます。プルリクエストへのレビューや、イシューからの修正などを自動にできます。公式のドキュメントは、APIキーをリポジトリに直接コミットせず、GitHubのシークレットに保存すること、ワークフローには必要な権限だけを与えること、取り込む前にClaudeの変更を確かめることを勧めています（出典：Claude Code 公式ドキュメント「Claude Code GitHub Actions」）。

開発・検証・本番の環境を分ける

いきなり本番の環境で試すのではなく、開発の環境で作り、検証の環境で本番に近い条件で確かめてから反映します。環境ごとに、使うデータとAIに渡す権限を分けておきましょう。

本番に出したあとで問題が見つかったときに、前の版へ戻す手順も、反映の手順と一緒に決めておきます。

フックで、守らせたい手順を機械で止める

CLAUDE.mdに書いた決まりは指示として読まれるだけなので、守られないことがあります。確実に止めたい操作があるときに使うのが、フック（Hooks）です。フックは、Claude Codeの動作の決まった場面で自動的に実行されるコマンドで、ツールを使う直前、ファイルが変わったあと、セッションの開始時など、場面ごとに設定できます（出典：Claude Code 公式ドキュメント「フック」）。

本番運用でとくに効くのは、ツールを使う直前に動くフック（PreToolUse）です。実行しようとしているコマンドを見て、条件に合わないときは拒否を返せるため、消去や本番への反映といった操作を、人の注意ではなく仕組みで止められます。公式のドキュメントでは、フックが終了コード2を返すか、拒否の判断をJSONで返すと、その操作が実行されないと説明されています。

AIコーディングを複数人で進めるなら、フックの設定もリポジトリに入れてバージョン管理し、担当者が変わっても同じ歯止めがかかる状態にしておきましょう。

サブエージェントで、実装とレビューを分ける

1つの会話の中で調査も実装もレビューも続けると、やりとりが増えるほど前提が埋もれ、指示からずれた修正が混ざりやすくなります。これを避ける仕組みがサブエージェントです。サブエージェントは、独自のコンテキスト、専用の指示、使えるツールの制限、独立した権限を持って動き、結果の要約だけを元の会話に返します（出典：Claude Code 公式ドキュメント「カスタムサブエージェントの作成」）。

本番運用に向けた使い方は2つあります。1つは、ログの確認やテストの実行といった出力の多い作業をサブエージェントに任せ、本筋の会話を汚さないことです。もう1つは、レビュー専用のサブエージェントを用意し、実装したものを別の視点で読ませてから人が確認する流れにすることです。使えるツールを読み取りだけに絞っておけば、レビュー役が勝手にコードを書き替えることもありません。

あわせて、Gitのブランチや作業用のコピー（git worktree）を業務ごとに分けておくと、複数の修正を同時に進めても、確かめる前の変更が混ざりません。ただしサブエージェントはそれぞれが別に動く分、利用料も増えます。費用の見方は利用料とトークンのコストを管理するで説明しています。

入力したデータがAIの学習に使われないか

Anthropicの公式ドキュメントでは、TeamプランやEnterpriseプラン、APIなどの商用の条件のもとでは、Claude Codeに送られたコードやプロンプトを生成モデルの学習に使わないとしています（自らデータの提供を選んだ場合を除く）。一方、個人向けのプランでは、設定によって学習に使われることがあります（出典：Claude Code 公式ドキュメント「データ使用」）。社内の誰が、どのプランで使うのか、外注先がどのプランや環境で作業するのかを確かめておきましょう。

アカウントと権限は自社が持つ

外部サービスのアカウントや認証の情報は自社が発行し、外注先には必要な範囲と期間だけ権限を渡します。パスワードをメールやチャットに書いてやり取りしないことも、最初に取り決めておきます。顧客の情報など機密性の高いデータは、外注先の環境に持ち出さず、自社の環境の中で扱ってもらう形が安心です。

AIが書いたコードをレビューとテストで確かめる

Claude Codeが書いたコードも、人がレビューし、テストを通してから本番で使うのが前提です。どんなデータで、何件、どの結果を確かめたのかを記録に残してもらいましょう。テストの記録が残っていれば、あとで直したときに、前と同じように動くかを比べて確かめられます。

認証キーやパスワードをコードに残さない

APIキーやパスワードは、コードに直接書かず、環境変数やシークレットを管理する仕組みに置きます。鍵を書いた設定ファイル（.envなど）は、バージョン管理に入れないようにします。CI/CDで使う鍵も、リポジトリではなく、GitHubのシークレットなどに保存します。

Claude Code自体にも、鍵のファイルを読ませない設定があります。公式のドキュメントでは、Read(./.env)のような読み取りの拒否ルールを加えると、そのファイルを読む操作を止められると説明されています（出典：Claude Code 公式ドキュメント「権限を設定する」）。

コマンドの実行とファイルの操作をどこまで許すか

Claude Codeの権限は、許可（allow）、確認（ask）、拒否（deny）のルールで決めます。ルールは拒否、確認、許可の順に評価されるため、拒否したものは、ほかの設定で許可しても実行されません。管理者が配る管理設定は、利用者やプロジェクトの設定で上書きできないため、組織として守らせたい決まりはここに置きます（出典：Claude Code 公式ドキュメント「権限を設定する」）。

注意したいのは、コマンドの拒否ルールは書かれたとおりのコマンドに当てはまるもので、すべての呼び出し方を止める境界にはならない点です。より強く分けたい場合は、ファイルやネットワークをOSの段階で分けるサンドボックスや、開発用のコンテナの中で動かす方法が公式に案内されています（出典：Claude Code 公式ドキュメント「セキュリティ」）。最初は1つずつ確認しながら使い、扱う範囲がはっきりしてから自動にする範囲を広げていきましょう。

生成されたコードの脆弱性と、追加されたパッケージを確かめる

AIが書いたコードには、入力の確かめ漏れや、権限の確認漏れといった脆弱性が混ざることがあります。Claude Codeには、今のブランチの変更をセキュリティの観点で確かめる/security-reviewコマンドもあります（出典：Claude Code 公式ドキュメント「セキュリティ」）。ただし、こうした機械の確認は補助と考え、最後は人が判断します。

あわせて、AIが新しく追加した外部のパッケージ（ライブラリ）も確かめます。実在して保守が続いているものか、既知の脆弱性がないか、本当に必要かを見て、使う版を固定しておきましょう。

ライセンスと著作権の扱いを確かめる

追加したパッケージには、それぞれ利用の条件（ライセンス）があります。社内で使うだけか、社外に配るかで守る条件が変わることもあるため、本番に出す前に一覧にして確かめます。生成されたコードが、既存のコードと似すぎていないかにも気を配りましょう。

外注する場合は、AIが書いたコードを含む成果物の権利が、どちらに帰属するのかを契約で決めておきます。決め方は成果物の権利の帰属を契約で決めるで説明しています。判断に迷う点は、自社の法務の担当者や顧問の弁護士と確かめてください。

外部のツールやデータにつなぐとき（MCP）の注意

Claude Codeは、MCP（Model Context Protocol）という仕組みで、課題管理のツール、データベース、社内のAPIなどにつなげられます。貼り付けた内容から作業させるのではなく、その仕組みを直接読み書きできるようになるため、業務の自動化では使う場面が多い部分です（出典：Claude Code 公式ドキュメント「MCP を使用して Claude Code をツールに接続する」）。

一方で、つなぐ先が増えるほど、AIが触れる範囲も広がります。公式のドキュメントは、接続する前に各サーバーを信頼できるか確かめること、外部の内容を取り込むサーバーはプロンプトインジェクション（外部の文章に混ぜた指示でAIを動かす攻撃）の危険にさらされることを警告しています。社外で作られたものを試す前に、どの会社が作り、何を読み書きするのかを確かめましょう。

チームで使う接続先は、プロジェクトの設定ファイル（.mcp.json）に書いてリポジトリで共有できます。この形で共有された接続先は、各自が中身を確認して承認するまでつながらないため、知らないうちに接続が増えることを防げます。本番の業務データにつなぐ接続先は、読み取りだけに絞れないかを先に検討してください。

誰が読んでから本番に出すかを決める

Claude Codeで作った変更は量が多くなりがちで、読む人がいないまま本番に入ってしまうことがあります。AIに指示した人とは別の人が変更を読んでから本番に出す、という流れを決めておきましょう。社内に読める人がいない場合は、レビューだけを外部に頼む方法もあります。

レビューで見る点は、毎回そろえておくと漏れが減ります。差分の範囲が依頼どおりか、テストが足されているか、鍵や個人情報がコードに入っていないか、権限を広げる変更がないか、追加されたパッケージは必要なものか、の5つが基本です。

監視とログで、止まったことにすぐ気づく

本番で動く仕組みは、いつ、何を受け取り、どう処理し、どこで失敗したのかをログに残します。仕組みが止まっていないかを定期的に確かめる死活監視と、エラーが起きたときに社内のチャットなどへ通知が届く設定もあわせて用意しましょう。

止まったときに、誰が最初に見て、どこまでを自分で直し、どこから外注先に頼むのかも決めておきます。仕組みが直るまでのあいだ、業務を人の手に戻す手順があれば、業務そのものを止めずに済みます。

増えたコードと資料を、定期的に片づける

AIで機能を足し続けると、似た処理が別々の場所に増えたり、使われていないコードが残ったりします。こうした技術的負債は、あとで直すときの手間とリスクを大きくするため、機能を足す期間と片づける期間を分けて、定期的に整理しましょう。

READMEや手順書、CLAUDE.mdも、コードと一緒に更新します。公式のドキュメントでは、CLAUDE.mdの中で指示が食い違っていると、Claudeがどちらか一方を選んで従うことがあるとしています（出典：Claude Code 公式ドキュメント「Claude があなたのプロジェクトを記憶する方法」）。古い指示を残さないことも、品質を保つ手入れの1つです。

AIのモデルや外部サービスの更新に備える

外部サービスの仕様の変更や、AIのモデルの更新によって、作った仕組みが前と同じように動かなくなることがあります。使うパッケージや外部サービスの版を記録し、更新があったときはテストを通してから切り替えるようにしておきましょう。

AIの答えを業務の中で使う仕組みでは、更新の前後で、同じ入力に対する答えを比べられるよう、確かめ用のデータを残しておくと安心です。止まったときに誰が直すのかは、保守の契約を結ばない場合でも決めておきます（運用・保守の費用も参考にしてください）。

役割分担と承認の流れ

小さな会社では1人が複数の役割を兼ねることもありますが、少なくとも「作る人」と「本番に出すことを承認する人」は分けておくと安心です。

AIの利用ルールに書いておく項目

利用ルールは、細かく作り込むより、現場が迷う点に答えられることを優先します。AIコーディングの本番運用では、次の項目を入れておきましょう。

ルールは文書で配るだけでなく、守らせたいものは設定にも落とし込みます。Claude Codeでは、管理者が組織全体のCLAUDE.mdや管理設定を配ることができ、公式のドキュメントは、動き方の指針にはCLAUDE.mdを、技術的に止めたいものには管理設定の拒否ルールを使うよう分けています（出典：Claude Code 公式ドキュメント「Claude があなたのプロジェクトを記憶する方法」）。

利用料とトークンのコストを管理する

Claude Codeの利用料は、使う量によって大きく変わります。公式のドキュメントでは、企業への導入全体で平均のコストは開発者1人あたり1稼働日で約13ドル、月額で150〜250ドルとされ、90%のユーザーは1稼働日あたり30ドル以下だとしています（出典：Claude Code 公式ドキュメント「コストを効果的に管理する」）。使うモデル、コードの量、自動化の使い方で変わるため、公式も小さなグループで試して基準をつかんでから広げることを勧めています。

管理の手段は、契約の形によって違います。TeamプランやEnterpriseプランでは管理者が支出の上限を設定でき、APIで使う場合はClaude Consoleでワークスペースごとに上限を設けられます。GitHub Actionsで動かす場合は、1回の実行のやり取りの回数やワークフローの時間に上限を設けると、想定外の利用を防げます（出典：Claude Code 公式ドキュメント「Claude Code GitHub Actions」）。利用料を誰が負担するかは、外注の場合はClaude Codeの利用料はどちらが払うかもあわせて確かめてください。

作りたい業務はあるのに、作れる人が社内にいない

IPAの『DX動向2026』では、AIの導入・運用上の課題として「専門人材が不足している」が50.1%で最も多く、DXを進める人材の量が「やや不足」「大幅に不足」と答えた企業は合わせて85.5%にのぼります（出典：IPA『DX動向2026』）。自動化したい業務がはっきりしていても、仕組みに落とし込める人がいないために止まっている企業は少なくありません。

小さな業務の自動化でも頼みやすくなった

以前は、外注するなら数百万円規模のシステム開発になることが多く、1つの業務の手作業を減らすために外注するのは割に合いませんでした。Claude Codeで作る時間が短くなったことで、集計や転記といった小さな業務の自動化でも、外部に頼む選択肢が現実的になっています。

依頼先を見極める情報が足りない

一方で、依頼先選びに悩む企業も多くいます。中小機構の調査では、AI・ITの導入について「適切なベンダーや製品を選定する情報が十分にある」に当てはまらないと答えた中小企業が79.8%でした（出典：中小機構『中小企業のAI等の利活用に係る実態調査』2026年3月）。Claude Codeを使うと掲げる会社が増えるほど、比べ方を知っておくことが大切になります。

業務の自動化

表の集計や突き合わせ、ファイルの整形、定型のレポートづくり、メールや帳票からの転記など、毎日や毎月くり返す作業を自動で回す仕組みです。手順が決まっていて件数の多い業務ほど、効果が出やすくなります。

社内ツール

申請やチェックの画面、社内の情報を探す検索の画面、案件や在庫の管理表を置き換える小さな業務システムなどです。市販のツールでは業務に合わず、表計算ソフトで無理に回している業務が対象になりやすいでしょう。

外部サービスとの連携

会計ソフト、顧客管理（CRM）、チャット、クラウドストレージなどをつなぎ、手で行っていたデータの受け渡しをなくす仕組みです。つなぐサービスの数が増えるほど、作る手間と確かめる手間が増え、費用も上がります。

AIを組み込んだ仕組み

社内の文書をもとに質問に答える仕組みや、問い合わせの一次対応、書類の読み取りと仕分けなど、生成AIを業務の流れに組み込む仕組みです。AIの答えには誤りが含まれることがあるため、どこで人が確かめるかまで設計してもらう必要があります。

外注に任せにくいもの

次のようなものは、外注しても期待どおりにならないことが多いため、進め方を分けて考えます。

外注に向いている業務かのセルフチェック

頼みたい業務について、次の6つを確かめてみてください。「はい」が多いほど、外注で効果が出やすい業務です。

外注の効果は、作る技術よりも、対象の業務がどれだけ整理されているかで決まります。3番や4番に「いいえ」が多い場合は、開発の前に業務の棚卸しから始めるのが近道です。

外注するメリット

一番のメリットは、早く確実に動くものが手に入ることです。経験のある担当者が作るため、試行錯誤にかかる時間を短くでき、セキュリティや権限の設計、テストの進め方といった、社内では見落としやすい部分も最初から組み込めます。本番運用に必要な監視やログ、反映の手順まで含めて頼めるのも利点です。社員が本来の業務から離れずに済む点も見逃せません。

外注するデメリット

デメリットは、費用がかかることと、作り方の知識が社内に残りにくいことです。中身が分からないまま納品されると、少し直すたびに依頼が必要になり、外注先に頼り続ける状態になります。この点は、後の章で説明する納品物と権利の決め方で防げます。

内製が向いているケース

社内にプログラムの経験者がいて、対象の業務も小さく、多少止まっても困らない場合は、内製から始めてもよいでしょう。業務の担当者が自分で使いながら直していく形なら、Claude Codeの強みをそのまま生かせます。その場合も、本記事の前半で紹介したレビューと権限の決まりは、社内で用意しておきましょう。

判断の目安

外注と内製は、どちらか一方を選ぶものではありません。最初は外注で動くものを作り、運用と小さな改善から社内に移していく進め方が現実的です。社内で作る力を育てる方法は AI内製化支援とは もあわせてご覧ください。

費用の内訳

見積もりを比べるときは、どの項目まで含んだ金額なのかをそろえることが大切です。構築費が安くても、業務の整理や接続、保守が別料金になっていれば、総額は逆転します。

作るもの別の費用の目安

Claude Codeを使った開発の外注では、次の金額が目安です。業務の複雑さや連携の数で上下するため、あくまで相談の出発点として見てください。

同じ内容を従来の方法で開発する場合に比べると、作る時間が短くなる分、費用は抑えられる傾向にあります。ただし、要件の整理やテスト、引き継ぎの手間は大きく変わりません。安さだけで選ばず、テストと引き継ぎの工程が見積もりに入っているかを確かめましょう。

運用・保守の費用

稼働したあとの運用・保守は、月数万円程度から、定例の打ち合わせや改善まで含めると月数十万円程度まで幅があります。外部サービスの仕様の変更やAIのモデルの更新で、作った仕組みが動かなくなることもあるため、止まったときに誰が直すのかは、保守の契約を結ばない場合でも決めておきましょう。

Claude Codeの利用料はどちらが払うか

Claude Codeは、Anthropicの有料プランやAPIの利用料がかかります。法人向けにはTeamプランやEnterpriseプランがあり、Enterpriseプランはシートの料金に、使った量に応じた料金を加える形です（出典：Claude 公式の料金ページ）。開発中に外注先が使う利用料と、稼働後に自社で使う利用料を、どちらが負担するかを見積もりの段階で分けておきましょう。プランごとの違いは Claude Codeは非エンジニアでも使える でも説明しています。

見積もりで確かめる5つの点

見積書を受け取ったら、次の5つを確かめます。

AIBUILDERZに依頼する場合の費用の決まり方

参考として、AIBUILDERZでの費用の考え方を紹介します。システム構築は成果報酬型で、業務アプリの構築費は事前にいただかず、実際に稼働させ、効果をご確認いただいてからお支払いが始まります。

対象の業務や支援の範囲によって条件が変わるため、詳しくはサービス資料でご確認ください。

請負｜完成した成果物に対して払う

決めた仕様のものを完成させて納めることに対して代金を払う形です。完成の基準がはっきりしている開発に向いています。仕様をあとから変えると追加の費用になりやすいため、最初に決める範囲を絞っておくことが大切です。

準委任｜作業や工程の実施に対して払う

決めた工程や作業を行うことに対して代金を払う形です。業務の整理や設計のように、やってみないと結論が決まらない工程に向いています。外部サービスやAIの出力のように、相手側の事情で結果が揺れる部分を含む開発でも使われます。

伴走型｜月額で相談と改善を続ける

月額で、構築や改善、相談を続けて受ける形です。小さく作って直しながら広げるClaude Codeの開発と相性がよく、本番運用に入ってからの改善や、社内に作り方を移していく場合にも向いています。月に何をどこまで行うのかを、契約で決めておく必要があります。

スポット｜試作や調査だけを頼む

1つの業務の試作（PoC）や、接続できるかどうかの調査だけを、短い期間で頼む形です。本格的に作る前に、効果と作れるかどうかを確かめたいときに使います。

4つの形の比較

実際には、業務の整理と設計は準委任、構築は請負、稼働後は伴走型というように、工程ごとに形を分けることもよくあります。工程ごとに、何をもって終わりとするかを書面で決めておくことが大切です。契約で確かめる点は、経済産業省の「AIの利用・開発に関する契約チェックリスト」や、IPAの「情報システム・モデル取引・契約書」も参考になります。

PR｜AIBUILDERZ AI導入支援サービス

PR

AIBUILDERZ｜AI導入支援サービス

システム構築は成果報酬型。AI研修から導入・構築・定着まで一気通貫で支援

AI研修からシステムの導入・構築・定着まで、一気通貫で支援するサービスです。業務アプリの構築費は事前にいただかず、実際に稼働させ、効果をご確認いただいてからお支払いが始まります。成果報酬型での対応は、当社が小規模と定義するシステムが対象です。

• 業種・規模を問わず支援どの業務からAIやシステムに置き換えるかを一緒に決め、効果の大きい業務から順に進めます。
• システム構築は成果報酬型業務アプリの構築費は事前にいただきません。稼働させ、効果をご確認いただいてからお支払いが始まります。
• AI導入の効果を可視化置き換える業務を一覧にし、導入前後の時間から、空いた時間とかからなくなった費用を毎月記録します。
• 小さく始めて、リスクを管理影響の小さい業務から始め、AIの実行結果は担当者が確認・承認してから反映します。

サービス資料をダウンロード無料診断を申し込む

システム開発会社

従来から受託開発を行ってきた会社が、開発の道具としてClaude Codeを使う形です。大きなシステムや、既存のシステムとの深い連携に強い一方で、発注は要件定義から始まる大きな単位になりやすい傾向があります。

AI導入支援・構築代行の会社

業務の整理から、AIを使った仕組みの構築、稼働後の運用までをまとめて請け負う会社です。どの業務から手をつけるかの判断から相談できるため、社内にIT担当者が少ない企業に向いています。会社によって、研修や内製化の支援までを含むかどうかが分かれます。

フリーランス・クラウドソーシング

クラウドソーシングのサービスなどを通じて、個人に頼む形です。小さな自動化や試作を安く早く頼める一方で、担当者が1人のため、稼働後の保守や引き継ぎ、セキュリティの体制は自社で確かめる必要があります。

外注先を選ぶ7つの観点

実績の数よりも、自社に近い業務で何を作り、相手の社内に何が残ったかを具体的に話せるかを見ましょう。

相談のときに聞いておきたい質問

最初の打ち合わせで、次のように聞いてみると、各社の違いが見えやすくなります。本番運用に入ってからの質問は、外注先に聞く質問と、答えの見方にまとめています。

見送ったほうがよい提案

業務の話を聞く前に作るものを決めてしまう提案や、「何でも自動化できます」と範囲を決めない提案は注意が必要です。仕組みを外注先の環境でしか動かせず、ソースコードも渡さないという条件の場合も、将来の乗り換えや社内での改修が難しくなります。テストやレビューの話が出てこない提案も、本番運用を任せるには不安が残ります。

仕組みを動かす環境を、自社の管理下に置く

作った仕組みが外注先のサーバーやアカウントで動いていると、契約をやめた時点で使えなくなるおそれがあります。サーバーやクラウド、外部サービスのアカウントは自社の名義で用意し、外注先には作業に必要な期間だけ権限を渡す形にしましょう。

AIBUILDERZでも、AIのツールやサーバーはお客さまに発行・契約していただき、当社は選定と設定を行って、権限だけをお借りしています。契約が当社にあると、解約したときにお客さまの資産が消えてしまうためです。

成果物の権利の帰属を契約で決める

ソースコードや設定、手順書などの成果物の権利がどちらに帰属するのかを、契約書に書いておきます。外注先が前から持っている部品や雛形は外注先に残ることが多いため、自社に帰属するものと、利用を許諾してもらうものを分けて確かめましょう。AIが書いたコードの扱いや、自社のデータを使ってできたものの扱いも、あわせて決めておくと安心です。

納品物の一覧を決める

動く仕組みだけでなく、直すために必要なものも納品物に入れます。

動く仕組みと一緒に、直すための資料まで納品物に入れることが、外注先に頼り続けないための一番の備えです。

社内への引き継ぎの終わり方を決める

将来、社内で運用や改善を担いたい場合は、引き継ぎの終わり方を最初に決めます。たとえば「社内の担当者が手順書だけで日々の操作を終えられる」「軽い修正を社内で1回やり終える」など、確かめられる形で決めておくと、支援をいつまで続けるかで迷いません。

契約の前に確かめるチェックリスト

契約書の細かな条文は、自社の法務の担当者や顧問の弁護士と確かめましょう。

期間の目安

1つの業務の自動化なら、相談から稼働まで1〜2か月程度、外部サービスとの連携を含む社内ツールなら2〜4か月程度が目安です。社内の確認や、外部サービスの権限の手続きに時間がかかることが多いため、発注する側の担当者の時間もあらかじめ確保しておきましょう。

発注する側が用意するもの

業務の手順が分かる資料、実際の帳票や画面、件数の分かるデータ、外部サービスの管理者の権限、そして確認と判断をする担当者です。担当者の確認が止まると、開発全体が止まります。

失敗1：中身が分からず、直すたびに依頼が必要になる

ソースコードや手順書を受け取らず、外注先の環境で動かしていると起きやすい失敗です。動かす環境を自社の管理下に置き、直すための資料まで納品物に入れることで防げます。

失敗2：権利の帰属を決めずに、あとで揉める

ほかの会社に保守を移そうとしたときに、成果物を自由に使えないことが分かるケースです。自社に帰属するものと、利用を許諾されるものを、契約の前に書面で分けておきましょう。

失敗3：見積もりは安かったのに、追加の費用がかさむ

つなぐサービスや件数が、見積もりの前提より増えると起きやすい失敗です。前提の条件と、増えたときの金額を見積書に書いてもらい、総額で比べます。

失敗4：いきなり大きく作り、現場で使われない

現場の手順と合わず、作ったのに使われないまま終わるケースです。1つの業務で試作し、担当者が使えることを確かめてから広げます。

失敗5：「AIを使っている」という言葉だけで選ぶ

AIを使うと掲げていても、実務での使い方は会社によって大きく違います。どの業務で、どのくらいの期間使っているのか、品質をどう確かめているのかを、具体的に聞いて確かめましょう。

公開前の確認表

本番に出す前に、次の項目をすべて確かめます。1つでも「いいえ」があれば、出す前に手当てを済ませましょう。

外注先に聞く質問と、答えの見方

本番運用まで任せる外注先を選ぶときは、次のように聞いてみましょう。答えが具体的かどうかで、本番運用の経験が見えてきます。

相談の前にまとめておく情報

相談の前に次の情報をまとめておくと、外注先の見積もりや提案の精度が上がり、各社を同じ条件で比べやすくなります。