AIで自作した社内ツール、「運用している」と言える3段階

社内ツールとは、社員が業務のために社内で使う道具のことです。AIで自作した社内ツールを「運用している」と言えるのは、作った本人が見ていない時間も動き、社員がURLを開いて使え、止まった日に誰が動くかまで決まっている状態です。この記事では、今どの段にいるかの判定と、段を上げる最小条件を書きます。

僕はAIVESTという会社を経営していて、経営しながら自分でもAIで社内の仕組みを作っています。

2026年9月時点で「社内ツール 自作」の検索上位は、自作の手段や費用、コード管理までを丁寧に扱っています。一方で、作ったものを「運用している」と言ってよいかの判定は見当たりませんでした。この記事はそこだけを扱い、作り方と費用は書きません。

社内ツールとは？「作った」と「運用している」は別の状態です

社内ツールの例は、集計表、見積もりの下書きを作る画面、問い合わせを振り分ける仕組み。社内の業務を回すために持つ道具の総称です。

AIで社内ツールを自作できるようになって、この言葉の中身が2つに割れました。「作った」と「運用している」です。

「作った」は作った人の画面の話

「作った」は、作った本人の画面で期待どおりに動いた、という事実です。

数字が出た、ボタンが押せた、ファイルができた。ここまでは、AIが最短で連れていってくれます。

「運用している」は作った人がいない時間の話

「運用している」は、別の問いに答えられる状態です。本人がパソコンを閉じた後も動くか。本人以外が開けるか。止まった日に誰が何をするか。

システム運用は、情報システムを止めずに動かし続ける仕事全般を指す言葉です。この記事では社内ツール1本に絞り、この3つの問いに答えがある状態を「運用している」と定義します。

「作った」の延長線上に、自然に「運用している」があるわけではありません。 間に、別の作業が挟まります。

なぜAIで自作した社内ツールは「localhost止まり」になるのか

localhost（ローカルホスト）とは、自分のパソコンの中だけで開ける住所のことです。作った本人のパソコンでは画面が開けても、隣の席の社員のパソコンからは開けません。

2026年9月9日、X上で「身近な管理職がClaude Codeで社内業務ツールを作ったと話すが、これまで見てきたものは全部localhostだった」という趣旨の投稿が、投稿から約21時間で約34.7万回表示されていました（2026年9月10日にX上で観測した表示回数で、このブログの実測ではありません。出典参照）。

反応の中には「自分が見ている間だけ動くものを、動くと呼んでいた」という言葉もありました。

AIの完了の合図は「本人の画面で動くこと」

AIに社内ツールを作らせると、完了の合図は本人の画面で動いたことになります。

その先の置き場や公開範囲は、会社の決めごとがなければ、AIに聞いても決まりません。localhost止まりの原因は技術の壁ではなく、決めていないことです。

「試作」と「運用」を分ける言葉がない

もう1つの原因は、段階を分ける言葉がないことです。

自分のパソコンで動いたものも、全社員が毎日使っているものも、同じ「作った」で呼ばれます。言葉が1つしかないと、発表してよい時期も、手を離してよい時期も決められません。そこで、3段階に分けます。

社内ツールの運用は3段階で判定する

判定は次の3段階です。各段に、はいかいいえで答えられる質問を1つずつ置きました。

判定はいちばん弱い条件で決まる

URLは社員に配ってあるのに、毎朝自分がパソコンで起動しないと動かない。この場合は2段目ではなく1段目です。

判定は満たしている条件の多さではなく、満たしていない条件のうち、いちばん低い段で決めます。

段は飛ばせない

2段目を経ずに主管だけ決めても、誰も使っていないツールの持ち主が増えるだけです。社員が使って初めて、止まったときに困る人と主管の仕事が生まれます。

1段目から2段目へ。置き場・入口・壊れたときの連絡先の3点を決める

1段目から2段目に上げるのに、作り直しは要りません。決めるのは、置き場・入口・壊れたときの連絡先の3点だけです。

置き場は自分のパソコンの外に

置き場は、自分のパソコンの電源と無関係に動く場所です。

どこに置いてよいか、社外から見えてよいかは、会社が先に決める規約です。決め方は別の記事に書きました。

関連記事バイブコーディングで作った社内ツール、業務に載せてよいかバイブコーディングで非エンジニアも社内ツールを作れる時代になりました。問題は「業務に載せてよいか」の判断基準です。AIで社内ツールを多数内製している僕が、作る・公開する・やめるの線引き5つを実物つきで解説します。→

入口はURLを1本に

入口は、社員がブックマークできるURL1本です。開いた最初の画面に、何をするツールかを1行で書きます。

入口が複数あると、どれが正しいかを作った人に聞きに来ることになり、1段目に戻ります。

壊れたときの連絡先は画面から分かるように

画面の端に「動かないときはこの人へ」と名前を1つ書きます。

2段目の時点では、作った本人の名前で構いません。連絡先が画面にあるだけで、社員は壊れたときに使うのをやめず、知らせる側に回れます。

試しの操作と本番を同じ経路に置かない

社員が使い始めたら、作った人が試す操作と、社員が使っている本番を分けます。

このブログでは、記事の投稿を先に手元の検証用サーバーと検証専用のデータベースで流す規約です（2026年9月時点）。本番側では、公開済みの記事に投稿を重ねないよう、投稿の仕組みが公開済みの一覧と突き合わせて止め、サーバー側でも拒否する二重の防衛を置いています。

公開済みの一覧が取れない日でも、サーバー側の拒否が最後に止める作りです。片方だけだと、その片方が静かに失敗した日に素通りします。

2段目から3段目へ。持ち主を「作った人」から外し、止まった日の動き方を先に決める

2段目から3段目で変わるのは、ツールの中身ではなく持ち主です。

業務ツールの主管は「その業務の持ち主」に置く

主管とは、そのツールを使い続けるか、止めるか、直すかを決める人です。

作った人は、異動や退職、繁忙期でいなくなります。主管は作った人ではなく、その業務ツールで回している業務の持ち主に置きます。 経理の集計ツールなら経理の責任者、問い合わせの振り分けなら窓口の責任者です。

主管は自分で直せなくて構いません。止まったと知り、直す人に頼み、直るまでの業務を決められれば足ります。

止まった日の動き方を3択で先に決める

稼働前に、止まった日の動き方を3つに分けて書いておきます。

3つ目だけは、止まった日の説明を自動返信に任せず、ツールの外に人を置く決めごとです。

止まっている間の縮退運転（機能を削って、止めずに最低限だけ回すこと）の組み方は、属人化は引き継ぎ書では解消しない。72時間しのぐ代替1本に分けて書きました。

毎朝の起動を人がやっていないか

3段目の手前でよく残るのが、毎朝の起動を作った人が手でやっている状態です。作った人が休んだ日に止まります。

2026年9月13日時点で、僕の作業環境に登録されている「決まった時刻に自動で立ち上がるジョブ」は70本、そのうち自社用に名前を揃えたものが53本です。決まった時刻に自動で動かす仕組みは、Claude Codeを毎朝定時に走らせるlaunchd自動化に書いています。

同時に2回起動しても壊れない作りにする

人の手を外すと、起動が重なる日や、前回が途中で落ちた日が必ず来ます。

僕の会社で毎朝、判断待ちの一覧を届けているジョブは、AIを介さず決まった手順を決まった順で流すだけの作りで、次の3つを守っています。

• 何度流し直しても結果が壊れない（同じものは1つと見なし、その日の分は上書きする）

• 同時に2つ走らないよう鍵をかけ、前回の異常終了で残った鍵は回収してから始める

• 失敗の記録は消さず、追記だけする

失敗の記録は監査証跡。削除禁止、追記のみ。

ジョブの冒頭に書いてある一文です（2026年9月時点）。失敗を消せると、止まった原因を主管が後から追えません。

動いているのに止まっている。僕の会社の所在表と生存確認の実物

3段目に上げた後で、いちばん気づきにくいのが、起動はしているのに成果が出ていない状態です。

全資産を4つの状態で持つ所在表

僕の会社では、アプリや自動化の仕組みといった資産を、1つの所在表で管理しています。2026年9月11日更新の所在表を9月13日に集計すると、登録は156件で、状態の内訳は次のとおりでした。

所在表の運用規約には、次の決まりがあります。

所在表に無いものは「未登録」と答え、推測でパスや数値を作らない。未登記は存在しない扱い。

台帳に載っていない社内ツールは、止まっても誰も探しに行けません。 だから、載っていないものは存在しないものとして扱います。

自動起動の登録はあるのに、稼働を誰も確かめていない3件

156件のうち3件は、状態欄に「自動起動の登録はあるが、稼働は未確認」という趣旨で書かれていました。

自動起動の登録があることと、動いていることは別です。

毎朝9時に起動し、取り込みゼロのまま終了していたジョブ

もう1件は、外部サービスからデータを取り込む、毎朝9時のジョブです。

2026年7月25日から外部サービスとの接続が切れたままで、ジョブは毎朝起動し、同じ失敗を記録にだけ書いて、再通知はせずに終了していました。9月13日の朝9時の記録にも、同じ行が残っています。

所在表では、このジョブは休眠中に分類され、毎朝走るのに実際の取り込みがゼロの「沈黙劣化」として記録されています。起動の記録だけを見ていると、この状態は正常に見えます。

同じ通知を毎朝繰り返さない作りは、通知の見過ごしを防ぐ判断です。ただ繰り返さないなら、別の場所で「成果が出ていない日数」を数える仕組みが要ります。

月1の生存確認で見る3点

僕の環境では、毎朝5時に検証と状態一覧の更新を回す仕組みも置いています（2026年9月時点）。それでも、起動したかと成果が出たかは、別の確認項目として持つ必要があります。

社内発表してよいのは2段目から。社内ツールを全社に広げる順番

1段目で発表すると、開けない社員が先に増える

1段目のまま社内発表すると、聞いた社員が開こうとして開けません。

「作った」の発表は、使えないことを確かめに行く社員を増やすだけです。

発表の言葉を段で分ける

広げる順番は、少人数の実業務から

1. 2段目に上げて、その業務を実際にしている数人に使ってもらう

2. 連絡先に来た問い合わせで、入口と画面の説明を直す

3. 主管と、止まった日の3択を決めて3段目に上げる

4. 所在表に載せてから、全社に知らせる

4番を最後に置くのは、全社に知らせた後に止まっても、探しに行ける状態にするためです。

配った後に使われ続けるかは人の側の設計で、AIを配っても使われない会社の共通点とAI活用の推進設計に書いています。

社内ツールの運用でよくある質問

出典

3段階の判定、段を上げる3点、止まった日の3択、生存確認の3点は、この記事での整理です。根拠に使った運用の実物は僕の会社のものです。「作った」で止まる状態が話題になっていることの観測には、次の投稿を使いました。

• devnago0氏のポスト（2026年9月9日）