AIエージェントで内製したツールが「作った人しか触れない」状態を避けるための保守設計を解説。ドキュメント自動生成、修正をエージェントに任せる運用、担当者交代への備え、廃止判断の基準を、断定を避けつつ実務目線で整理します。
AIコーディングエージェントの普及で、これまで外注や情シスの順番待ちが必要だった小さな業務ツールを、現場の担当者が自分で作れるようになってきました。数時間から数日で動くものができるのは大きな前進です。一方で、多くの組織で少し遅れて表面化するのが「作ったあとの管理」です。作る速度が上がったぶん、社内に散在するツールの数も一気に増え、半年ほど経った頃に「これは誰が作ったのか」「なぜこの処理になっているのか」が分からないツールが積み上がっていきます。
この現象は、担当者の怠慢というより構造的なものだと考えられます。従来のシステム開発では、要件定義書・設計書・テスト仕様書といった中間成果物が自然に残り、それがそのまま引き継ぎ資料になっていました。ところがエージェントとの対話で作る開発では、成果物は「動くコード」と「やり取りの履歴」だけになりがちで、後から見て意図をたどれる形の文書が残りにくいのです。作った本人の頭の中には文脈があるので困りませんが、その人が異動・退職・多忙になった瞬間、ツールはブラックボックスに変わります。
内製の利点は、思いついたものをすぐ形にできることです。しかしこの手軽さは、裏返せば歯止めの効きにくさでもあります。承認プロセスも予算審査も通さずに作れるため、似た目的のツールが部署ごとに乱立したり、一度きりの用途で作ったスクリプトが業務に組み込まれたまま残ったりします。作ること自体のコストが下がった結果、維持すべき対象だけが静かに増えていく、という状態が起きやすいと考えられます。
内製ツールの保守で問題になるのは、たいてい次の三つが重なったときです。第一に属人化で、作った一人しか動かし方も直し方も分からない。第二に仕様不明で、何を入力すると何が出るのか、どんな前提で動いているのかが書かれていない。第三に放置で、業務が少し変わっても直されず、いつの間にか結果がずれていることに誰も気づかない。個別には小さな問題ですが、三つが同時に進むと「怖くて触れないが止めるわけにもいかないツール」ができあがります。
本記事では、こうした状態を避けるための最低限の保守設計を扱います。前提として、大がかりなIT統制や重厚なドキュメント体系を新設する話ではありません。現場が自分で作り続けられる自由を保ったまま、作った人が抜けても回る状態をどう安く作るか、という視点で整理します。内製そのものを進めるか外部に委ねるかの判断については、社内AIエージェントは内製か外注かもあわせて参照いただくと、保守負担まで含めた比較がしやすくなると考えます。
内製ツールの管理と聞くと、資産台帳・変更管理・レビュー承認・監査ログといった重厚な仕組みを想像しがちです。しかしそれらを最初から全部そろえようとすると、現場が「面倒だから作らない・報告しない」方向に流れ、かえって管理外のツールが増える逆効果になりやすいと考えられます。内製の良さは軽さにあるので、保守の仕組みも軽さを壊さない範囲で設計するのが現実的です。
すべての内製ツールを等しく手厚く管理する必要はありません。一度使って捨てるスクリプトと、毎日の基幹業務に組み込まれたツールを同じ基準で扱うのは非効率です。まずは「壊れたら業務が止まるか」「間違った結果を出したら誰かが困るか」の二軸で、重点管理すべきツールを絞り込むことをおすすめします。この選別をせずに全体を管理しようとすると、労力が分散して結局どれも中途半端になりがちです。
重点対象について、まず以下の4点が用意できていれば、作った人が抜けても致命傷になりにくいと考えます。順に「何があるかの一覧（台帳）」「各ツールの説明（READMEと変更履歴）」「直せる状態（修正の再依頼手順）」「引き継ぎ先（担当と代替の明示）」です。それぞれの詳細は次節以降で扱いますが、いずれも高度な仕組みではなく、置き場所と更新のきっかけを決めるだけで成立します。
保守が続かない典型的な原因は、保守作業が普段の作業動線から外れていることです。台帳や文書を別のシステムに分けてしまうと、更新が後回しになり陳腐化します。可能なら、ツールを作る場所・動かす場所と、台帳や文書を置く場所を近づけ、作った流れのまま記録が残るようにするのが望ましいと考えます。社内AIエージェント基盤や社内ナレッジ基盤を持っている場合、そこに保守情報も集約すると動線が一本化しやすくなります。
内製ツールのドキュメントが残らない最大の理由は、書くのが面倒で後回しになるからです。人手で保守文書を書き続ける前提に立つと、忙しい時期に必ず途切れます。ここでAIエージェントを活用できる余地が大きいと考えられます。すなわち、ツールを作る・直すのと同じエージェントに、説明文書も生成・更新させてしまう発想です。
エージェントは、既存のコードやスクリプトを読んで「これは何をするツールか」「どんな入力を受け取り何を出すか」「どんな前提・制約があるか」を要約するのが比較的得意です。作成直後だけでなく、後から既存ツールに対してもREADME相当の説明を起こさせることができます。完全に正確とは限らないため人の確認は要りますが、白紙から人が書くより負担が小さく、ゼロよりはるかにたどりやすい文書が残ると考えられます。
自動生成させる際は、出力フォーマットを社内で共通化しておくと後の一覧性が上がります。目的・利用部署・入出力・実行方法・依存する外部サービス・既知の注意点・最終更新日、といった項目をテンプレート化し、どのツールも同じ見出しで説明されるようにします。フォーマットが揃っていれば、担当外の人が読んでも同じ場所に同じ情報があり、引き継ぎの心理的ハードルが下がります。プロンプトやテンプレートの社内共有の考え方は、内製ツール全般の標準化にも通じます。
説明文書と同じくらい重要なのが変更履歴です。いつ・誰が・なぜ直したかが分かると、後任者が挙動の理由をたどれます。理想は、修正をエージェントに依頼したときに、その修正内容の要約を履歴として自動で追記させることです。人が別途書き起こすのではなく、直す作業の副産物として履歴が積み上がる形にできれば、更新漏れが起きにくくなると考えます。
ここで注意したいのは、自動生成された文書を無条件に信じないことです。エージェントは、コードに書かれていない業務上の意図までは推測になりますし、事実と異なる説明を自信ありげに書くこともあります。生成物はあくまで下書きとして扱い、重点管理ツールについては作成者や利用部署が一度目を通して補正する運用が前提だと考えます。自動生成は「文書を書く手間」を減らす道具であって、「内容を保証する仕組み」ではない、という線引きが大切です。誤りとの付き合い方は、ツール開発以外の生成AI活用でも共通する論点です。
保守で最も属人化しやすいのが「直す」工程です。作った本人なら勘所が分かるので数分で直せても、他の人には手が出せない、という状態が続くと、その人が保守のボトルネックになります。ここでの目標は、作った本人以外でも、エージェントに指示して安全に直せる状態を用意しておくことです。
エージェントに修正を任せられるかどうかは、渡せる文脈の質でほぼ決まると考えられます。ツールの目的、守るべき制約、変更してはいけない部分、テストの観点といった情報が、コードと同じ場所に残っていれば、後任者はそれをエージェントに読ませたうえで修正を依頼できます。逆に、こうした文脈が作った人の頭の中にしかないと、いくらエージェントが優秀でも、意図に反した直し方をしてしまう危険があります。文書化は、人の引き継ぎのためだけでなく、エージェントに正しく直させるための入力でもあるわけです。
修正を任せるうえで欠かせないのが、直した結果を確かめる手順です。内製ツールは小規模でも業務に組み込まれていることが多く、直したつもりが別の箇所を壊すことは起こり得ます。せめて重点管理ツールについては、代表的な入力と期待される出力を数件そろえておき、修正後にそれを流して結果が変わっていないかを確認する、という最低限の検証をルール化しておくことをおすすめします。検証観点そのものもエージェントに洗い出させ、人が取捨選択する進め方が現実的だと考えます。
修正を任せる範囲は、影響の大きさに応じて段階を分けるのが安全です。表示の文言や集計の見せ方といった影響の小さい変更は現場判断で進めてよい一方、本番データを書き換える処理や外部サービスへの連携に関わる部分は、実行前に人が内容を確認する承認点を置くのが望ましいと考えられます。「どこまでをエージェントに任せ、どこから人が確認するか」をツールの重要度ごとに決めておくと、スピードと安全のバランスが取りやすくなります。この線引きの考え方は、AIエージェント運用全般に共通する統制の基本でもあります。
単発で実行するツールと違い、サーバー上で常時動き続けるツールは、監視・再起動・障害対応といった運用の技術が別途必要になります。作れることと運用できることは別のスキルで、ここが手薄だと「動いているうちは放置、止まったら誰も対応できない」状態に陥りがちです。常時稼働のツールを増やすなら、それを運用できる人材を並行して育てる視点が要ります。VPS上でAIエージェントを常時運用できる人材を育てるで扱っている運用スキルは、内製ツールの保守体制を考えるうえでも参考になると考えます。
内製が進むと、いつの間にか「あの人しか分からないツール」が組織の各所にできあがります。その人が異動・退職・長期休暇に入った瞬間に業務が止まる、というのは内製の典型的なリスクです。ここでの狙いは、特定の一人に依存しない状態を、平時のうちに少しずつ作っておくことです。
まず出発点は、誰がどのツールを主担当しているかを台帳で見えるようにすることです。可視化しておくと、一人に負荷やリスクが集中している状態に気づけますし、その人が抜けるときに何を引き継ぐべきかが明確になります。台帳がないと、退職の引き継ぎ面談で「実はこれも私が作りました」が次々と出てくる、という事態になりがちです。棚卸しは、内製ツールが増えた組織ほど早めに一度やっておく価値があると考えます。
重点管理ツールについては、主担当だけでなく、いざというときに触れる代替担当をあらかじめ決めておくことをおすすめします。代替担当は必ずしも作り方を完全に理解している必要はなく、「文書とエージェントを使って、最低限の対応ができる」程度でも、完全な属人化よりはるかに安全です。ここでも、文書とエージェントで直せる状態を作っておく前段の設計が効いてきます。一人に集中させない体制は、社内でAIエージェント活用を広げる推進役を複数育てておく話ともつながります。
個々のツールの担当だけでなく、内製そのものを牽引し、他のメンバーの相談に乗れる推進役を組織内に複数持っておくと、保守の底力が上がると考えられます。一人のスーパー担当に依存する体制は、その人が抜けたときに一気に崩れます。むしろ、そこそこ分かる人を複数育て、互いに補完し合える状態のほうが持続的です。推進役の育て方については、社内にAIエージェントの推進役（チャンピオン）を育てるが参考になると考えます。
担当交代の際の引き継ぎは、生成された説明文書と変更履歴を土台に、作成時のエージェントとの対話ログ、そして短い口頭補足を組み合わせるのが現実的です。文書は「何を・どう」を伝えますが、「なぜこの設計にしたか」の背景は口頭のほうが早いことも多いためです。とはいえ口頭に頼りすぎると再び属人化するので、口頭で出た重要な背景はその場で文書に追記する、という往復を習慣づけることが望ましいと考えます。
内製の運用で見落とされがちなのが、作る仕組みばかりが整い、畳む仕組みがないことです。ツールは作れば作るほど維持コストが積み上がります。使われなくなったものを止められないと、保守対象だけが増え続け、いずれ全体を把握できなくなります。健全な内製には、廃止・凍結を判断する基準が欠かせないと考えます。以下は、放置されやすい典型的な落とし穴です。
棚卸しの際は、各ツールに対して次の三つを問うと判断しやすくなると考えます。第一に「直近で実際に使われているか」。ログや利用者への確認で、使われていないものは凍結候補にします。第二に「壊れたら本当に困るか」。困らないものは維持の優先度を下げます。第三に「同じ目的の代替があるか」。標準ツールやSaaSで代替できるなら、無理に内製を維持しない判断もあり得ます。この三つで、維持・凍結・廃止・統合のいずれかに仕分けていきます。
使われていないと判断しても、いきなり削除するのは危険です。実は月次や年次でしか使われていなかった、というケースがあるためです。まずは「凍結（実行を止めるが残しておく）」の段階を挟み、一定期間、誰からも問い合わせが来なければ廃止する、という二段構えにすると事故が減ると考えられます。凍結期間の長さは、そのツールが関わる業務の周期に合わせて決めるのが妥当です。
廃止判断は、思い出したときにやると結局やらなくなります。半期や四半期など、周期を決めて棚卸しをイベント化し、台帳を見ながら全ツールを維持・凍結・廃止に仕分ける場を設けるのが現実的です。ここでもエージェントに、各ツールの最終更新日・利用状況・依存関係を一覧化させ、人が判断する材料をそろえさせると負担が下がります。廃止まで含めた導入の全体像は、AIエージェントを社内に導入するにはの観点ともあわせて考えると、作りっぱなしを避けやすくなると考えます。
ここまで挙げた仕組みを一度に全部そろえる必要はありません。むしろ、いきなり重厚な体制を目指すと現場が離れ、内製の良さである軽さが失われます。最低限から始めて、痛みが出た箇所を順に厚くしていくのが、定着しやすい進め方だと考えます。以下は、あくまで一般的な目安としての段階です。実際の順序や粒度は組織の状況に応じて調整することが前提です。
最初にやる価値が高いのは、既存の内製ツールを棚卸しして台帳を作ることです。完璧でなくてよいので、何が・どこに・誰の手で存在するかを可視化します。この段階で、把握していなかったツールや、すでに使われていないツールが見つかることが多いと考えられます。台帳ができれば、次に何を厚くすべきかの優先順位も見えてきます。
次に、台帳の中から「壊れたら困る」重点ツールを選び、説明文書・変更履歴・簡単な検証手順をそろえます。文書はエージェントに下書きさせ、人が補正します。ここまでで、作った人が急に抜けても、他の人が文書とエージェントを頼りに最低限の対応ができる状態に近づきます。全ツールにやる必要はなく、重要度の高いものから順に広げるのが現実的です。
最後に、修正をエージェントに任せる手順、本番影響のある変更の承認点、定期棚卸しの三つを運用に組み込みます。ここまで来ると、作る・直す・畳むが一つのサイクルとして回り始め、ツールが増えても管理不能になりにくくなると考えられます。ただしこれは到達点ではなく、業務や体制の変化に合わせて更新し続ける前提のものです。
本記事で示した仕組みは、あくまで一般的な整理です。どこまでの体制が必要かは、内製ツールの数・重要度・組織の人員・扱うデータの機微さによって変わり、机上だけで最適解を決めるのは難しいと考えます。Nsightは産業用画像検査で培った、現場で動く仕組みを検証しながら作り込む姿勢を、社内AIエージェントや業務OSの内製化支援にも持ち込んでいます。元キーエンス画像処理事業部出身の監修者の知見を踏まえつつ、「作って終わり」にしない保守設計を、貴社の実際のツール群と運用を見ながら一緒に確かめていくことをおすすめします。まずは既存ツールの棚卸しと、重点ツール一つの保守設計を小さく試すところから、現物で検証していくのが着実な出発点だと考えます。
必ずしも専任は必要ないと考えられます。重要なのは人数より仕組みで、台帳・説明文書・修正の再依頼手順・代替担当の四点がそろっていれば、兼任でも回りやすくなります。むしろ最初から専任体制を組もうとすると重くなり、内製の軽さが失われがちです。まずは重点ツールに絞って最低限を整え、痛みが出た箇所から厚くしていく進め方が現実的だと考えます。
下書きとして使う前提であれば有効だと考えます。エージェントはコードから使い方や入出力を要約するのは比較的得意ですが、業務上の意図の推測や、事実と異なる記述が混じることはあります。したがって重点管理ツールについては、生成された文書に作成者や利用部署が一度目を通して補正する運用が前提です。自動生成は書く手間を減らす道具であって、内容を保証する仕組みではない、という線引きが大切だと考えます。
まず、その人が関わったツールを台帳として洗い出すことをおすすめします。そのうえで、業務に組み込まれている重点ツールについて、目的・前提・注意点をエージェントに文書化させ、本人に補正してもらいます。あわせて、いざというときに触れる代替担当を決め、文書とエージェントで最低限直せる状態にしておくと安全性が高まります。口頭で出た背景は、その場で文書に追記して残すことが望ましいと考えます。
いきなり削除せず、凍結の段階を挟むことをおすすめします。月次や年次でしか使われていないツールもあるため、まず実行を止めて残しておき、一定期間どこからも問い合わせが来なければ廃止する二段構えが安全です。凍結期間は、そのツールが関わる業務の周期に合わせて決めるのが妥当だと考えます。判断は思い出したときではなく、定期的な棚卸しの場で行うと抜け漏れが減ります。
変わると考えます。単発実行のツールは、動かない時に手動で対応すれば済むことが多い一方、サーバー上で常時動くツールは監視・再起動・障害対応といった運用の技術が別途必要です。作れることと運用し続けられることは別のスキルであり、常時稼働ツールを増やすなら、それを運用できる人材の育成を並行して進める視点が要ります。重要度に応じて、どこまで手厚く運用するかを分けるのが現実的です。
増えた内製AIツールの棚卸しと、重点ツールの保守設計を、貴社の実際の運用を見ながら小さく検証するところから始められます。元キーエンス画像処理事業部出身の監修者の知見を踏まえ、属人化しない体制づくりをご一緒します。
内製ツールの保守設計を相談する