「アプリを作れる」と
「業務システムとして使える」の間にあるもの

AI で「作れる範囲」は大きく広がりました

専門のエンジニアに依頼しなければ難しかったアプリケーションでも、AI を活用することで、自社でかなりのところまで実装できるようになっています。これは非常に大きな変化です。

• 画面を作る
• データを登録する
• 検索する
• 地図上に情報を表示する
• 担当者を割り当てる

一方で、会社の業務で継続的に利用するシステムには、「画面上で機能が動くこと」以外に、その周囲に多くの設計・運用・管理項目があります。

中心にあるのは「アプリの機能」

最も目に見えやすい部分です。営業支援アプリであれば、例えば次のような機能があり、AI による開発で最も大きく効率化されるのがこの領域です。

• 地図に表示 — 顧客を地図上に置く
• 検索 — 顧客を名前で探す
• 絞り込み — 条件で対象を絞る
• 担当の割り当て — 営業担当者を決める
• 訪問の記録 — 訪問済みを付ける
• 登録・変更 — 顧客情報を直す
• 管理画面 — 全体を見渡す
• 操作履歴 — 誰が何をしたか

この部分だけを見ると「これなら自社でも作れる」という判断になることは、現在ではまったく不自然ではありません。

全体像 — アプリの機能の周囲にある領域

画面から見えているのは中央の「アプリの機能」。会社の業務として使う場合には、周囲を含めて初めて一つのシステムになります。

ただし周囲のすべてを等しく行う必要はなく、影響の大きさ×起こりやすさに応じて選びます（第2部の終わりの「重要度の階段」）。

認証 — 誰が使っているのかを確かめる

最初に必要になるのが「誰がこのシステムを使っているのか」を確認する仕組みです。ログイン画面があるだけでは十分とは限りません。

• ユーザーごとのID管理
• パスワード管理
• 多要素認証
• LINE WORKS 等との一括ログイン（SSO）
• 退職者アカウントの停止
• パスワードを忘れた場合の復旧
• 不正ログインへの対策
• ログイン失敗回数の制限
• ログイン状態（セッション）の管理
• 無操作時の自動ログアウト

権限管理 — 何を見せ、何を操作させるのか

ログインできた後には、「その人に何を見せ、何を操作させるのか」を決める必要があります。

立場によって範囲が異なる

一般社員・営業担当者・営業責任者・管理者・経営者・システム管理者 — 立場ごとに、見えてよい情報・操作できる範囲が異なる場合があります。

細かな制御の例

• 自分の担当顧客だけ見られる／自分の営業所だけ見られる／全社を見られる
• 顧客情報を変更できる人・削除できる人
• ユーザーを追加できる人

データ — どこに置くか・正しい状態を保てるか

どこに置くかの判断

• どのデータベースを使うか／国内に置くか／クラウドでよいか
• 個人情報をどこまで保存するか／外部サービスへ渡してよいか
• 暗号化するか／本番データを開発で使ってよいか／テストデータの準備

正しい状態を保つ仕組み

• 同じ顧客の二重登録を防ぐ／2人が同時に更新しても片方の変更が消えない
• 消してはいけないデータが消えない削除・更新のルール
• 入力チェック／表形式ファイル（CSV）の取込で既存データを壊さない

画面上では見えにくい部分ですが、業務システムでは非常に重要です。

間違えたときに戻せるか — バックアップと復旧

業務では必ず操作ミスが起きます。例えば「営業担当者が間違えて500件の顧客を削除してしまった」ということもあり得ます。

誤操作の後に戻せるか

• 削除前の状態に戻せるか／何時の状態まで戻せるか
• 誰が変更したか分かるか／個別のデータだけ復元できるか

「削除ボタンが動く」だけでなく、誤操作が起きた後に会社として復旧できるところまでが運用です。

バックアップの設計と訓練

• 何時間ごとに取るか／何日分残すか／本番と別の場所に置くか
• 本当に復元できるか — 定期的な復元テストと、所要時間・問題点の記録

「毎日取っていたが、半年間壊れたバックアップを保存していた」ということもあり得ます。

監視と障害対応 — 壊れたときの設計

監視 — 気付ける仕組み

• アプリ・サーバー・データベースが動いているか
• エラーが増えていないか／ディスク容量は足りているか
• 外部サービスが止まっていないか／不正アクセスが起きていないか

「お客さんから電話が来て初めて障害に気付く」という状態を避けるための仕組みです。

障害対応 — 決めておくこと

• 誰が検知し、誰に連絡するか／夜間や休日はどうするか
• 何分・何時間以内に対応するか／サービスを止めてよいか
• 復旧方法は決まっているか／原因調査をどう行うか

操作履歴・監査ログとセキュリティ

誰が・いつ・何をしたのかを残す

• 誰がログインしたか／誰が顧客情報を見たか
• 誰が変更したか（変更前と変更後の値）／誰が削除したか
• 管理者権限を誰が変更したか

保存期間・管理者自身の操作の記録・後から書き換えられない仕組み、まで考えます。

攻撃・事故への備え

• 不正ログイン／パスワード総当たり／画面や外部との接続口（API）の作りの穴を突く攻撃
• 権限の不備／設定ミスによる公開／接続用の鍵（APIキー等）の漏えい
• 基本ソフト（OS）や部品（ライブラリ）の更新・脆弱性情報の確認を継続する

性能と、外部サービスとの関係

性能 — 増えたときに動くか

• 顧客1,000件なら速い → 10万件になると検索が遅い
• 100人が同時にアクセスすると止まる／地図に大量表示すると重い
• 想定ユーザー数・同時利用者数・データ件数・応答時間・将来の増加量を考える

外部サービス — 相手の都合で変わる

Google マップ・LINE / LINE WORKS・メール・SMS・決済サービス・クラウドサービスなどの外部サービスには、利用料金・利用回数の制限・利用規約・サービス停止・仕様変更・ログイン方式の変更といった「相手の都合」があります。

環境の分離・変更管理・テスト

環境を分ける

• 開発・テスト・本番を分ける（本番を直接触ると、一つのミスで業務が止まる）
• 誰が本番へ反映できるか／どの版が本番で動いているか／前の版へ戻せるか

変更の影響を管理する

• 入力項目を1つ足すだけでも、データベース・画面・表形式ファイル（CSV）・帳票・権限・テスト・マニュアルへ波及し得る
• 誰が変更を決め、影響範囲をどう確認し、いつ本番へ反映するか

テストの範囲

• 正常な入力だけでなく、異常な入力・空欄・長い文字・同時操作・通信切断・権限のないユーザー・大量データ
• 機能を足したとき、以前動いていた部分が壊れていないか（回帰テスト）

記録・引き継ぎ・費用・終わり方

なぜこの設計かを残す

• 構成・データベース設計・権限設計・運用方法・重要な意思決定の理由
• 「作れるから記録しなくてよい」ではなく「簡単に記録できるので残しておく」

属人化の本当の意味

• 1人で作ること自体は属人化ではない。問題は、その人がいないと判断・復旧・変更・引き継ぎができない状態
• 退職・異動・長期不在でも業務は続くよう、アカウント・契約・ソースコードを会社の管理にする（事業継続の問題）

継続費用を見込む

• サーバー・データベース・外部との接続口（API）・地図・監視・証明書などの月額が続く
• 利用が増えたとき、月1万円が月10万円・50万円になる可能性も考える

終わり方まで考える

• データを取り出せるか／CSV等で移行できるか／特定サービスに縛られていないか／完全に削除できるか
• 作り始めるときに、終わり方まで考えておく

AI によって変わったこと

ここまでの整理は「だから自社開発はやめた方がよい」という話ではありません。むしろ逆です。AI によって、アプリの実装だけでなく、設計書の作成・テストの作成・セキュリティチェック・ドキュメント作成・運用手順の作成・コードレビューまで、以前より大幅に効率化できます。

そのため、自社で開発できる範囲はこれからますます広がります。設計・実装・テスト・安全確認・文書・運用手順といった複数の役割を、1人または少人数で兼ねる（兼務する）ことも現実的になりました。

「AI があれば、全部できるのでは？」 — はい、かなりできます

まず、そのとおりです。実装・調査・文書・テストの多くは AI で大きく効率化でき、当社自身もそのように作っています。そのうえで整理したいのは、AI で減るものと減らないものの対比です。

AI で減るもの

• 実装の工数／調査の工数
• 文書・マニュアル作成の工数／テスト作成の工数
• 必要な人数

AI でも減らないもの

• 最終判断（何を採用するかを決めること）
• 責任（結果を引き受けること）
• 承認（変更を通してよいと決めること）
• 継続運用（回し続けること）
• 説明責任（社内外へ説明すること）

「何人いるか」ではなく、「何役が成立しているか」

プログラムを書ける人が3人いても、次の役割が決まっていなければ十分とは限りません。逆に、2〜3人でもこれらの役割が成立していれば、強い体制です。ここまで見てきた「周囲」は、人数の話ではなく役割の話です。

• 設計を決める役
• 安全（セキュリティ）を見る役
• 運用を回す役
• 変更を承認する役
• データに責任を持つ役
• 社内外へ説明する役

AI で「兼務」が現実的になった

• 設計・実装・テスト・安全確認・文書・運用手順を、1人または少人数で横断できる範囲が大きく広がった
• 役割の数だけ人を雇う必要はない。少人数のまま、役割を成立させられる

それでも「役割の定義」は要る

• 誰がどの役を担い、どこまで判断してよいかを決めて、書いておく
• 兼務するほど、役割の境目は意識して引く必要がある（次の節）

役割を兼務する体制の落とし穴と、その手当て

自己レビュー・自己承認になりやすい

• 1人＋AI で開発からレビュー・テスト・本番反映まで完結すると、実質すべてが自己承認になる
• 複数の AI を使っても、採用を決める人が同じなら、役割の分離にはならない

手当ては「相互の確認」を要所だけに

• すべての変更を別の人の承認にする必要はない
• 顧客情報・認証・権限・本番のデータベース・安全設定など、重大な変更だけ別の人の確認を入れる — 影響の大きさで決める

限界が出るのは「同時多発」のとき

• 平常時は AI でかなり回せる。障害・脆弱性・問い合わせ・外部サービスの変更・新規開発が同時に来たときが問題
• AI は並列で作業できても、判断・承認・説明する人は並列にならない — そこが詰まる

知らない論点は、AI に質問できない

• AI は聞けば答えるが、論点を知らなければ聞けない。バックアップなら「取っているか」だけでなく、目標復旧時点・目標復旧時間・復旧試験・保管場所の分離まで
• 専門性とは、答えを知っていることより「何を問うべきか」を知っていること

問いは「作れるか」ではなく「どう責任を持ち続けるか」

多くの場合、AI を使えば作れます。決めるのは「任せるか、任せないか」ではなく、判断の置き場所と確認の置き場所です。

自社で判断する

• 業務ルール・機能と改善の優先順位・日常運用の判断
• 判断の主体は、つねに自社の手元に置く

第三者確認を要所に入れる

• 重大な変更（顧客情報・認証・権限・本番データ・安全設定）は、作った本人と別の目で確認する
• 別の目は、社内の別担当でも外部でもよい。別系統の AI は確認の補助になるが、採否を決める人が同じなら分離にならないため、確認する人自体を別に置く

専門性が必要なときだけ支援を使う

• 論点の洗い出し・設計の確認・監査の観点など
• 常駐でも丸投げでもなく、必要な場面だけ

企業システムとして、さらに外側にある領域

会社として継続利用するシステムでは、アプリの周囲に加えて、インフラ・ネットワーク・調達・リリース・運用・セキュリティ・監査・文書化・教育・委託先管理といった領域まで含めて管理する必要があります。すべてを等しく行う必要はなく、システムの重要度に応じて選びます（この部の終わりに「重要度の階段」を示します）。

※ ISMS＝情報セキュリティを組織として管理する仕組み（第三者認証の制度もあります）

冗長化・可用性とネットワーク

一点の故障で全体が止まらないか

• 1台のサーバー・1本の回線・1つのデータベースだけなら、その一点の故障で全体が停止する
• サーバーの複数台構成／データベース・回線・電源などの二重化
• 「二重化しているから安心」ではなく — どの障害まで耐えるか・自動で切り替わるか・切替に何分かかるか・切替試験をしているか
• 目標復旧時間（RTO）・目標復旧時点（RPO）・許容停止時間を業務側と合意する

ネットワークの設計

• 拠点間通信・クラウド接続・インターネット接続の二重化
• 経路の制御（BGP 等の経路制御の仕組み）— 何を流し、障害時にどう切り替えるかまで管理する

ネットワークは普段見えにくい部分ですが、障害時には業務全体を止める可能性がある重要領域です。

調達・ベンダー管理と資産管理

調達・外部委託の管理

• 購入・契約の承認ルール／ベンダー選定基準／SLA（サービス品質の約束）の確認
• 個人情報の取り扱い／データの保管国／再委託の有無／契約終了時のデータ削除
• サポート期限（EOL＝提供終了）の管理／特定ベンダーへの依存の把握
• 委託先へどこまでアクセスを許すか・作業の証跡・終了時のアカウント削除

資産台帳 — 何を使っているかの一覧

サーバー・クラウドアカウント・ドメイン・利用サービス（SaaS）・ライセンス・証明書・接続用の鍵（APIキー）・プログラムの保管場所・バックアップ対象。

• 本番・開発・検証のどの環境に何があるかを明確にし、変更時に台帳・構成図も更新する

リリース管理 — 安全に本番へ反映する

AI によってコード修正は非常に速くなりました。だからこそ、本番への反映には明確なルールが要ります。変更 → 相互確認（レビュー）→ 自動テスト → 検証環境での確認 → 承認 → 本番反映 → 動作確認 → 問題があれば巻き戻し。確認と承認の深さは、変更の重大さに応じて変えます。

本番反映の方式にも設計があります。例えば Blue-Green 方式では、本番を二系統持ち、現在の本番（Blue）を動かしたまま新バージョン（Green）で動作確認・互換確認を済ませ、確認後に利用者の向き先を切り替えます。問題があれば Blue へ戻します。ただしデータベースの変更などは単純に戻せないため、リリース方式そのものを設計する必要があります。

変更の承認・運用ルール・権限の棚卸

変更を記録し、承認する

• AI の修正をそのまま本番へ入れる前に、確認の手順を設ける
• 変更理由・内容・影響範囲・テスト結果・承認者・戻し方を残す
• 重大な変更（顧客情報・認証・権限・本番データ・安全設定）は、作った本人と別の人の確認を入れる
• 緊急変更も「記録しなくてよい」ではなく、後追いで必ず記録・確認する

運用を手順書にする

• 日次・週次・月次の確認／バックアップ確認／証明書期限／障害の一次対応／退職者アカウントの停止 など
• 誰が・何を・どの手順で・どこまで判断してよいか・どこから上位者へ引き上げるか

AI はマニュアル作成を効率化しますが、運用ルールそのものは組織として決める必要があります。

アカウント・権限の棚卸

• 誰が申請し、誰が承認するか／退職時にいつ停止するか／異動時に見直すか
• 「この人に今もこの権限が必要か」を定期的に確認する
• 仕組みがあるだけでなく、実施した記録を残す

障害・課題・要望の管理 — 「言われたら直す」にしない

使い始めると、不具合の報告・改善の要望・使い方の質問が日々届きます。頭の中やチャットの流れの中で抱えず、台帳（1件ずつの管理票。チケットとも呼ばれます）に集めて管理します。流れは、起票（受付）→ 切り分け（不具合か・要望か・質問か）→ 優先度付け → 対応 → 確認 → 完了・記録、です。

受付を1か所に集める

• 利用者の問い合わせ・現場の気づき・監視の警報を、同じ台帳へ
• チャットで受けた報告も、台帳に起票してから扱う（流れて消えるのを防ぐ）
• 業務が止まる障害・情報の事故は、台帳を待たず直ちに連絡して初動へ。台帳には並行して（または事後に）記録する

台帳に残す項目

• 発生日時・事象・影響範囲・再現の手順・重要度・優先度
• 担当・状態（未着手／対応中／確認待ち／完了）・対応の内容・確認の結果

優先度の決め方をそろえる

• 重要度＝影響の大きさ、優先度＝重要度×緊急度、と定義をそろえて並べる。全部を最優先にしない（対策の深さを決める「影響×起こりやすさ」とは使い分ける）
• 未対応のまま忘れられた件を残さない（定期的に棚卸しする）

直して終わりにしない — 再発防止と、運営の定例

再発防止まで進める

• 影響の大きい障害・繰り返す問題は、「直った」で閉じずに、なぜ起きたかを一段深く掘る（操作の誤りなら、誤りにくい画面への改修まで考える）
• 同じ型の問題が、ほかの画面・ほかの処理に無いかを横並びで点検する
• 得られた教訓を、テスト・手順書・ルールへ反映する

利用者への共有

• 直せていない既知の不具合と、当面の回避のしかたを一覧で共有する
• 直ったら、報告してくれた方へ連絡する（報告するほど良くなる、という循環を作る）
• 止めて作業する日は、事前に告知する

定例で回す

• 月次などの定例で、件数・傾向・未完了・次の改修予定を報告する
• 重要度ごとの対応の目安（例: 業務が止まる障害は当日中に着手）をあらかじめ決めておく
• 課題の一覧と、決めたことの記録を残す — 会議は流れても、台帳は残る

定時の一括処理（バッチ）と、データの世話

画面の操作の裏では、毎朝の取り込み・日次の集計・通知といった決まった時刻の一括処理（バッチ）が動きます。ここは画面と別の設計が要る領域です。

ジョブの設計 — いつ・どの順で動かすか

• 決めた時刻に自動実行する仕組み（ジョブスケジューラ）で管理し、処理どうしの順序（先行・後続）を定義する
• 締めの処理・月末や祝日の扱い（実行カレンダー）・処理時間の余裕を設計する

失敗時の設計 — 止まったらどうするか

• 失敗の検知と通知／途中から再開できる設計／同じ処理をもう一度実行しても二重計上・二重送信にならない設計／二重起動の防止
• 終了予定を過ぎても終わらない「突き抜け」の監視と、手動でやり直す手順書

ファイル連携の設計 — 受け渡しを疑う

• 受け渡しの形式・文字コード・届く時刻の取り決め
• 届かない日・壊れたファイルの検知、再送の依頼、件数の突き合わせ（検品）までを設計する

データの世話 — ためたままにしない

• データごとに保存期間を決め、古いものは別置き（アーカイブ）または削除する
• ログの肥大化・ディスク容量・データ量の増加を監視し、データベースの性能を保つ手入れを続ける

脆弱性への継続対応 — 弱点は後から見つかる

脆弱性診断（検査）

• 作った後に、画面・外部との接続口（API）・サーバー・クラウド設定の弱点を検査する
• リリース前・大きな変更後・年1回など、重要度に応じて計画する
• 実施して終わりではなく、指摘の管理 → リスク評価 → 修正 → 再診断まで

脆弱性情報の見張り

• 使っている基本ソフト（OS）・部品・外部サービスに、後から弱点が見つかることがある
• どの情報源を・誰が見て・何日以内に評価し・重大なものは何日以内に直すかをルール化する
• 自動で知らせる仕組み（部品の更新通知など）も併用できる

更新の適用・提供終了の管理

• 修正版（パッチ）の適用対象・期限・テスト・本番反映・例外の管理
• 提供が終了した製品（EOL）は「動いているから使い続ける」ではなく計画的に入れ替える

ログの集約・事故対応・災害への備え

ログの集約と検知

• アプリだけでなく、機器・認証・クラウドの記録も集約する
• 不正ログイン・大量ダウンロード・不審な通信などを検知する（SIEM＝ログを集約して異常を見つける仕組み）
• 保管期間・改ざん防止・閲覧権限、機器間の時刻を揃えること（時刻同期。記録を突き合わせる前提）も管理する

事故（インシデント）対応

• その場の判断に頼らず、初動・隔離・証拠保全・調査を決めておく
• 顧客への報告・経営への報告・法令上の報告
• 夜間休日の連絡網・外部の専門会社・再発防止まで

災害への備え（事業継続計画・BCP）

• 地震・停電・回線断・クラウド障害・身代金要求型ウイルスまで想定する
• 遠隔地バックアップ・復旧の優先順位・代替手段
• 机上の計画だけでなく、訓練する

秘密情報・端末・教育・AI 利用の統制

秘密情報・鍵・証明書

• 接続用の鍵（APIキー）・パスワード類をソースコードに書かない／プログラム保管場所へ登録しない
• 専用の保管の仕組みで管理し、定期的に取り替える／証明書の期限を監視する／古くなった暗号方式は計画的に入れ替える

端末の管理

• パソコンの暗号化・画面ロック・ウイルス対策
• 紛失時に遠隔で消去できるか／廃棄時のデータ消去

教育・訓練

• セキュリティ教育・攻撃メールの訓練・管理者教育・事故対応の訓練
• AI の利用ルール（何を入力してよいか）も教育の対象になる

AI 利用の統制

• 許可する AI サービス／入力してはいけない情報（個人情報・認証情報・顧客情報など）
• AI が作ったコードのレビュー／AI による本番の直接変更の禁止
• 持ち込まれる公開部品（OSS）のライセンス確認と一覧化 — AI 経由に限らず、開発の経路を問わず行う
• AI が変更できる範囲と、人間の承認が必要な範囲を明確にする
• 利用する AI の変更・モデルの変更・サービス終了時の乗り換え先も、あらかじめ決めておく

ISMS・監査で見られるのは「仕組み・実施・証跡」

ISMS や監査で問われるのは、「ルール（規程に書く）→ 実施（そのとおりに行う）→ 証跡（記録を残す）→ 改善（見直して直す）」のサイクルです。

例: アカウントの棚卸

• 規程に「半年ごとに棚卸する」と書いてある
• 実際に半年ごとに棚卸する
• 実施結果を保存する
• 不要なアカウントを削除する
• 削除した記録を残す

バックアップ・更新の適用・脆弱性確認・教育・権限棚卸・事故対応の訓練なども、同じサイクルで管理します。

「作れるアプリ」の外側にある全体像

AI で速く作れるようになったのは中央の金色の枠の部分。AI は周囲の領域の整理・確認にも強力な支援になります。

補足 — このほかに検討しておきたい項目

データ移行と並行運用

• 既存の仕組みから乗り換えるとき、データをどう移すか・検証するか
• 新旧を並行して動かす期間、切替日、切替当日の入力先の決め方

法令・個人情報の扱い

• 個人情報保護法の義務（安全管理措置・第三者提供の制限と記録・重大な漏えい時の報告と本人への通知）
• 業種ごとの規制、利用規約の整備。判断に迷う点は専門家に確認する

利用者サポートと定着

• 問い合わせの窓口・使い方の教育・利用マニュアル
• 実際に使われているかの確認 — 定着しなければ、期待した効果は得られにくい

保守契約と責任の分かれ目

• 不具合の修正はどこまで無償か（契約不適合責任）・保守の範囲と費用
• 連絡の窓口・対応時間の約束（SLA）・契約終了時のデータの返還

重要度の階段 — どこまでやるかは、リスクで決める

第1部・第2部の項目を、すべてのシステムに等しく行う必要はありません。影響の大きさ×起こりやすさを見て、対策の深さを決めます。同じアプリでも、担う役割が上がるほど、求められる統制は上がります。

1. 補助アプリ例: 営業先を地図で見るだけ。止まっても不便で済む
2. 部門システム記録・担当割りを部門で共有。止まると部門の業務が滞る
3. 顧客管理（CRM）顧客情報・商談の履歴を持つ。誤った書き換え・漏えいがお客様への影響・信用に直結する
4. 会社の中核システム受注・請求・契約とつながる。止まると会社全体の業務が止まる

体制の成熟度 — 「内製か外注か」の二択にしない

「作れる」は最初の一段です。いまどの段にいるか・そのシステムにはどの段まで必要かで考えると、内製か外注かという二択から離れられます。

1. 作れる動くものを作って使える
2. 安全に変更できるテスト・環境の分離・変更の確認と承認
3. 障害から戻せるバックアップ・復旧試験・監視と障害対応
4. 誰でも引き継げる文書・会社管理・作った人が不在でも回る
5. 監査・継続改善ルール・証跡・改善のサイクルで回り続ける

AI が変える、発注と開発会社の関係

ここまでは、業務で使えるようにするための「周囲」の話でした。第3部は、外部への頼み方と確かめ方の話です。AI は、開発会社への頼み方・選び方・付き合い方そのものも変えつつあります。

• AI で試作してから見積もりを取る
• 提案書・見積書・契約書を AI で点検する
• 納品物を別の AI でレビューする
• 「見える」ことの代償も知っておく

AI で試作（プロトタイプ）を作ってから、見積もりを取る

従来の進め方では、文書の要件定義書 → 見積もり・発注 → 数か月の開発、と進み、完成間近で初めて動くものを見ることも珍しくありませんでした。そこで認識のずれ・手戻り・追加費用が生まれます。

これからは、AI で動く試作を数日〜数週間で作り（自社でも作れます）、その試作を共通の材料に見積もりを依頼する、という進め方が選べます。言葉の解釈ではなく、動くものが共通言語になります。

要件のずれが減る

• 現場が試作を実際に触って、足りない機能・要らない機能を先に洗い出せる

見積もりを比べられる

• 同じ試作を見た各社の見積もりは、内訳と考え方の差がはっきり出る

「周囲」が比較の要点になる

• 機能は試作で見えているぶん、認証・運用・保証といった「周囲」の説明が、見積もり比較の要点になる

※ ここでの対比は「文書中心で進めた場合」と「AI で試作を先に作る進め方の一例」であり、従来の進め方でも試作や段階確認を行う場合があります。

開発会社・パートナーを、AI でレビューする

提案書・見積書の点検

• 作業項目の抜け・二重計上・曖昧な前提を AI に洗い出させる
• 複数社の見積もりを突き合わせ、差の理由を質問できる形にする

契約書の点検

• 責任の分かれ目・検収の条件・再委託・解約時のデータ返還などのリスク条項を AI がレビュー
• 弁護士監修の専用サービスも提供されている。重要な契約の最終確認は専門家へ

納品物の点検

• 納品されたプログラム・設計書を、作った側と別系統の AI にレビューさせる
• 品質上の懸念を洗い出し、確認すべき点を具体的にできる。当社も、成果物を別系統の AI でレビューしてからお出ししています

ご注意 — AI のレビューにも誤りや見落としがあります。最終判断は人が行い、機密を入れる範囲は第2部の「AI 利用の統制」のルールとセットで運用します。

裏面 — 「見える」ようになったことの代償

この変化は、良いことばかりではありません。見る道具を持った発注側と、それを想定していない開発会社（またはその逆）の組み合わせは、新しいすれ違いを生みます。

指摘に応える工数は、何倍にもなる

• AI のレビューで、これまで見えなかった部分まで指摘が届く。細かな指摘まで全て埋めることを前提にすれば、開発会社はそれに応える工数を見積もりに織り込んでくる
• 実例: 世界中で使われる基盤ソフト curl では AI で作られた報告が急増し、2025年には全提出のうち本物の脆弱性が約5%まで低下。1件の検証に複数人で30分〜3時間かかり、2026年1月に報奨金制度の終了に至った

指摘を「送る」のは一瞬でも、「受けて検証する」のは人手のまま — ここに差が生まれます。

90% を 99% に煮詰める工数は、9% ではない

• 古くからの経験則:「最初の9割のコードに開発時間の9割、残りの1割にもう9割」（90:90 の法則）— 見た目の進捗と残りの工数は一致しない
• AI の時代も同様の指摘がある: AI で7割まで速く進んでも、残り3割（例外・安全・本番の品質）で行き詰まりやすい（「70% 問題」）
• 試作が動いて見えるほど「あと少しで完成」という誤解が生まれやすい。90→99 の煮詰めは 9% の上乗せではなく、そこまでと同等以上の工数がかかることも珍しくない

想定のずれは、互いの不幸になる

• AI を使いこなす発注側 × それを想定しない開発会社 — 指摘の量と深さに工数が追いつかず、要件が満たされない
• AI 対応の工数を織り込む開発会社 × それを知らない発注側 — 「AI で安くなるはず」とのすれ違い
• どちらの組み合わせでも、納期・費用・信頼が削れていく

この考え方は、当社自身にも適用します

この記事の内容は、読み手の皆様への注文ではありません。当社自身の AI 活用・少人数開発にも同じ原則を適用している、共通のものさしです。

当社の AI の使い方（開示）

• 実装・文書は AI で効率化し、成果物は作った側と別系統の AI でレビューする
• 重要な箇所は人が確認し、変更の履歴を残す
• お預かりした情報・プログラムを AI へ入力するのは、入力が学習に使われない契約・設定のサービスに限る
• 利用する AI・モデルの変更、サービス終了時の乗り換えは、影響を確認のうえ行う
• ソースコード・契約・アカウントは会社として管理する

顧問と受託の、責任の分かれ目

• 技術顧問としての助言は、判断と実施が支援先にある前提の支援
• 受託開発としてお受けした範囲は、受託した側が成果物に責任を持つ
• どちらの立場での発言かを、その都度明確にする

「最後に誰が判断するか」を決める

• AI・顧問・外注・社内担当と関係者が増えるほど、最終判断の所在が曖昧になりやすい
• 領域ごとに「実施する人」と「最終的に判断し、責任を負う人」を分けて決めておく

参考 — 発注のかたちの変化・工数と品質の壁に触れている記事

2026年8月24日時点で当社が確認した公開記事・学術発表・経験則です。内容は各著者の見解であり、当社の見解と異なる部分もあります。

「誰が作るか」ではなく、「必要な役割・責任・確認・継続性をどう成立させるか」

AI による内製は、十分現実的です。AI が減らすのは、主に作業の工数と必要な人数です。役割・責任・相互の確認・継続性・説明責任まで消えるわけではありません。

自社で判断する

• 業務ルール・機能・改善・日常運用の判断は、つねに自社の手元に
• AI の兼務で、少人数のまま多くの役割を担える

第三者確認を要所に入れる

• 重大な変更・安全・設計の要所は、作った本人と別の目で確認する
• 確認する人は、社内の別担当でも外部でもよい（別系統の AI は確認の補助として使う）

専門性が必要なときだけ支援を使う

• 論点の洗い出し・設計の確認・監査の観点など、必要な場面だけ
• 支援の出どころは問いません — 外部の専門家・監査・技術顧問など