AIで作った業務ツールは、半年後に誰が直すのか──保守を前提にした内製の設計

AIを使えば、非エンジニアでも動くツールが作れます。ここまでは、もう当たり前になりました。本当の分かれ目は、作った3ヶ月後・半年後に来ます。動かなくなったとき、直せる人が社内にいるかどうかです。

私たちはAirtable・GAS（Google Apps Script）・生成AIのAPIを組み合わせたAIエージェントを複数の実案件で本番稼働させ、自分たちで保守しています。この記事は、その現場で実際に起きた障害と、それを踏まえて契約書に書いている保守の線引きをそのまま書きます。

「動いている」と「運用されている」は違う

作るのは一度きりですが、運用は毎日続きます。そして運用フェーズで起きることは、作っているときにはほとんど見えません。

実際の数字で言うと、ある実案件では開発フェーズの見積りが全6ステップで約250万円でした。そのうち導入完了後3ヶ月の保守運用対応費として20万円〜が、当初から契約に含まれています。つまり構築費用の1割弱を、作り終えた後の3ヶ月分としてあらかじめ別枠で確保しているということです。

ここを見積りに入れていない発注・内製計画は、ほぼ確実に後から揉めます。「作ったら終わり」という前提そのものが間違っているからです。

重要なのは、下2つは「保守」ではないということです。ここを混ぜると、保守費用が青天井になります。後述の契約の項で詳しく書きます。

実際に壊れるのは、この3パターン

実案件で起きた「静かな故障」の正体

3パターンの中でも、最も気づきにくいのが1つ目です。実際に起きた事象をそのまま書きます。

メールをトリガーにして情報を取り込むエージェントで、「特定の送信元からのメールだけが取り込まれていない」という事象が起きました。エラーは出ていません。他のメールは正常に処理されています。一見すると動いています。

原因の切り分けに数日を費やした末、認証系のトラブルか、取得条件の不備かという2つの仮説に絞られました。最終的な原因は後者です。元の仕様が「未読メールの中から最新のものを取得し、処理完了後に既読にする」という設計になっていたため、システムが処理する前に人間がメールを開いてしまうと、永久に処理対象から除外されてしまう構造だったのです。誰も過失を犯していないのに、ツールだけが静かに止まります。

この種のトラブルは、コードをいくら眺めても見つかりません。「問題なく動く前提」と現場の運用フローにズレが生じた瞬間に発生するからです。対策として設計を見直しました。既読・未読といった人間が操作するステータスをトリガーにするのをやめ、システム専用の「処理済みラベル」を付与する方式に変更する。自前で一意の処理済みフラグを管理する方が、はるかに安全で確実です。

「壊れたと気づく」までの時間を短くする

意外に見落とされがちなのが、表の3番目にある「成功通知」です。エラー時のみ通知する設計にしておくと、システム自体が起動しなくなった場合に通知すら送信されず、異常に気づけません。「本日も正常に処理を完了しました」という定期通知を1日1回送信する仕組みを設ける方が、静かな障害の早期発見には有効です。

認証情報の置き場所が、一番の弱点になる

実務で最も事故になりやすいのが認証情報まわりです。理由は単純で、動かすために必要なのに、正しく扱う手順が誰にも共有されていないからです。実案件のSlackログを見返すと、APIキーやアクセストークンがチャットにそのまま貼られている場面が複数ありました。開発中のスピードを優先した結果ですが、これはチャットの検索履歴に永久に残るということでもあります。退職者もそのチャンネルを見ていたかもしれません。

実案件で保守が一気に楽になった転換点もあります。それまでは自社の環境でツールを作り、動作不良の報告を受けるたびに自社側を直し、それをクライアント側の環境へ反映する流れでした。環境が2つあるので、反映漏れが起きるし、再現確認もできない。そこでクライアント側の共用アカウントを使わせてもらい、クライアントの環境に直接スクリプトを置いて、そこで動作確認と保守をする形に変えたところ、運用工数が大きく下がりました。

AIツール特有の壊れ方——確率的にズレる

従来のプログラムと決定的に異なるのは、同一の入力を与えても毎回同じ結果が出力されるとは限らないという点です。この不確実性が、保守の難易度を押し上げます。実案件のPoCフェーズで記録された課題メモには、次のような生の声が残されています。

とりわけ1点目は構造的な難題です。「システムが故障しているのか」それとも「たまたま確率のブレで誤出力したのか」の判別がつきません。再現性のない不具合は、根本原因の特定が極めて困難です。

プロンプトの精度改善そのものの進め方は、AI推進をひとりで任された人が、最初にやるべきことでも触れています。

コストも「静かに」壊れる

稼働が止まることだけが障害ではありません。想定外に利用コストが跳ね上がることも、重大な運用事故のひとつです。生成AIのAPIは基本的に従量課金制なので、処理対象のデータ量が増大すれば請求額も比例して増加します。実案件でも、検証の過程でトークン消費量を抑制するために一部のAI機能を一時停止する判断を下したことがあります。開発直後は少量のテストデータで検証するため安価に思えますが、本番環境で実データを流し始めた途端、コストの桁が変わるケースは珍しくありません。

さらにリスクが高いのが、過去のやり取りや文脈情報を蓄積し続ける設計のエージェントです。適切な制限をかけずに放置するとコンテキスト長が肥大化し、気づかないうちに請求額が跳ね上がる事態を招きます。私たちも、コスト予測が立たないことを理由にクライアントへの導入を見送った構成があります。

備え方：作るときに決めておく4つ

とりわけ4番目が重要です。社内のすべてのツールに、一律で強固な保守体制を用意する必要はありません。半日止まっても代替手段があるツールと、停止が即座に基幹業務のストップにつながるツールとでは、講じるべき対策のレベルが根本から異なります。

引き継ぎ資料は「A4で1枚」から始める

網羅的な仕様書の作成を目指すと、結果としてドキュメント作成自体が放置されます。実際の現場で機能しているのは、次の項目だけをA4用紙1枚程度にまとめたシンプルな資料です。

特に最後の「触ってはいけない場所」を明記しておくと、誤操作による障害を大幅に抑止できます。実案件でも、管理画面の設定テキストを書き換えたことでスクリプトが異常終了したケースがありました。また、スプレッドシートの列名が勝手に変更されるのを防ぐため、該当セルを自動で保護する機能をわざわざ開発要件に追加したこともあります。変更されたくない設定は、注意喚起で守るよりも、仕組みで保護する方が確実です。

内製すべきもの／外注すべきもの

保守を外注するなら、契約で決める5項目

保守業務を社外に委託する場合、金額の交渉よりも優先して合意すべき項目があります。この定義が曖昧なまま依頼すると、トラブル発生時にどこまで対応してもらえるのかが毎回議論になり、対応が遅れます。実際の保守契約で定義している主要項目を挙げます。

もっとも重要なのは最後の「保証しないもの」です。AIの出力精度は「保証」の対象に設定できません。受託者として善管注意義務に基づき最善は尽くしますが、確率によって結果が揺らぐ出力を100%保証することは構造上不可能だからです。この前提を明記しないまま進めると、「期待した通りの回答が得られない」というクレームが障害報告として寄せられ、双方にとって不毛な結果を招きます。

同様の理由で、「何が保守の対象外か」を明確にしておくことは、対象を定義すること以上に重要です。仕様変更や追加要望を通常の障害対応と混同すると、保守コストは確実に跳ね上がります。パートナー選定の段階でこれを見極める方法は、Airtable開発会社の選び方の「見積書は、金額ではなく『含まれていないもの』を見る」にまとめています。

「保守を外注に握られたくない」という動機

商談の場で、多くの企業から異口同音に寄せられる声があります。それが「ツールの保守をいつまでも外注先に依存したくない」という課題感です。これは外部ベンダーへの不信感ではなく、軽微な改修のたびに見積りと発注の手続きが発生し、継続的な費用負担から抜け出せなくなる構造への警戒です。

この問題意識は、システムの設計要件にも直接反映されます。ある案件では、将来的な複数拠点への展開を見据えて「プログラミングを不要とし、設定画面上の入力変更のみで拠点ごとの独自要件に対応できること」を品質要件として明文化しました。現場の担当者が扱える範囲を設定値として外部化しておけば、展開拠点が増えるたびに開発会社へ追加発注する必要がなくなります。

同じ案件では、ツールに関する操作質問を受け付ける社内向けチャットボットの設置案も出ました。日常的な問い合わせの一次対応を仕組みで吸収できれば、保守フェーズの人的負荷そのものが下がるからです。

だから私たちは、作ったものを社内で直せる状態にして引き渡すことを設計の前提にしています。ツールを納品して終わりではなく、保守できる人を育てるところまでが仕事だと考えているからです。実際、非エンジニアの方にAIツールの作り方・直し方を身につけてもらう研修も行っています（非エンジニア企業でClaude Code研修をやった実録）。

最後の項目が、実質的に一番効きます。引き渡し先が1人だけだと、その人が異動した瞬間にパターン03へ逆戻りします。

半年後のためのチェックリスト

半分も埋まっていないなら、それは「動いているツール」であって「運用されているツール」ではありません。

まとめ

AIで作った業務ツールで問題になるのは、コードの品質より環境の変化と、人の記憶です。実案件で起きた障害も、根っこはコードのバグではありませんでした。人間が先にメールを開いてしまう、Bot名を変えたらトークンが変わる、設定画面の文言を変えたらスクリプトが落ちる——作った人と使う人のあいだにある前提のズレが、時間をかけて表面化しただけです。

だから対策も、技術ではなく設計と運用に寄ります。作る前に「止まったら誰が困るか」を決める。目的と手順を残す。失敗に気づける仕組みを入れる。人間が触る場所を制御に使わない。この4つだけでも、半年後の景色が変わります。

そして保守体制を作れない領域には手を出さない——これも立派な判断です。AIで作れる時代に残る価値は、「作れること」ではありません。作った後、現場で回り続けさせることです。