業務に合うツールを探して、比較サイトを何時間も眺めた経験はないでしょうか。候補を3つまで絞って、無料トライアルを申し込んで、結局「自社の業務とは微妙に合わない」で終わる。あるいは導入はしたものの、使っているのは機能の1割で、毎月のライセンス費用だけが積み上がっていく。
この記事の主張はシンプルです。2026年の今、「ちょうどいいSaaSが無い」業務は、AIに小さな社内ソフトを作らせるのが現実的な選択肢になりました。ただし何でも内製すればよいわけではありません。基幹は買う、すきまは作る。この線引きの判断基準と、私たちKOIYALが実際に自社用の管理画面を作らせて運用している実録、そして内製するときの安全設計まで書きます。
前提: 大事なシステムほど、買うべき
先に「作らない方がよいもの」から書きます。逆説的ですが、これがこの記事で一番重要な判断基準です。
会計、給与、顧客管理、メール、ファイル共有。こうした基幹の業務は、広く使われている大手のサービスを選ぶべきです。理由は4つあります。
第一に、集合知。利用者が多いツールは、困ったときに検索すれば答えが出てきます。AIに質問しても正確な回答が返ってきやすい。マイナーなツールはこの蓄積がありません。
第二に、人材。広く使われているツールなら、使える人を採用できます。担当者が辞めても引き継げます。
第三に、連携。他のツールとの接続手段が揃っています。マイナーツールは連携のたびに苦労します。
第四に、存続確率。サービスが終了するリスク、更新が止まるリスクは、事業規模に反比例します。
導入時の楽さでツールを選ぶと、この4つを見落とします。ツール選びで本当に大変なのは導入ではなく、運用と、やめるときです。特に「導入した担当者以外が扱う場面」で、マイナーツールの弱さは一気に表面化します。
それでも残る「すきまの業務」
基幹を大手で固めても、必ず残る業務があります。
自社独自の帳票の集計。特定の取引先向けの資料整形。社内の申請フローの一部。複数ツールにまたがる数字を毎週転記して眺める作業。どれも「専用SaaSを月額で契約するほどではないが、手作業では地味に時間を食う」業務です。
従来、この層の選択肢は3つでした。手作業を続ける。Excelマクロを誰かが作る(そして作った人が異動して誰も触れなくなる)。開発会社に発注する(小さな業務には見積りが合わない)。
ここにAIという4つ目の選択肢が入りました。要件を日本語で伝えれば、AIが動くソフトを書く。開発会社に頼むほどではない小ささの業務にこそ、この選択肢は効きます。
実録: 自社の管理画面をAIに作らせた
私たちが実際に運用している例を紹介します。KOIYALの社内には、会社の状態を一望するための管理画面(ポータル)があります。各業務のキューの残り数、対応が必要な項目、承認待ちの案件、人間のTODOリスト。毎朝これをブラウザで開いて、その日の動きを決めます。
このポータルは市販品ではありません。Claude(AIエージェント)に要件を伝えて作らせた、自社専用の小さなソフトです。実物の仕様を書きます。
- 本体はサーバー(137行)と画面(123行)の2ファイル、計260行。外部ライブラリはゼロで、実行環境の標準機能だけで動く
- 社内のPCの中だけで完結する。インターネットに公開しないので、ログイン機能も課金もいらない
- 画面は4ブロック。①主要な数値の一覧 ②安全な集計スクリプトをボタンで実行 ③判断が必要な作業はAIへの指示文をコピーするボタン ④人間のやることリストの読み書き
- 会社の状態データは、もともと社内で管理しているテキストファイルをそのまま読む。ポータルは「表示の窓口」に徹する
作るのにかかった時間は、要件の言語化と動作確認を含めて半日程度です。月額費用はゼロ。もし市販のダッシュボードSaaSで同じことをやろうとしたら、データ連携の設定だけで挫折していたはずです。自社のデータの持ち方が独特(テキストファイル管理)なので、市販品では「業務をツールに合わせる」改造が必要になるからです。
業務の独自性が高い×失敗しても影響が小さい。この条件が揃う業務が、AI内製の主戦場です。
小さなツールは、1つでは終わらない
ポータルの話には続きがあります。1つ作って味をしめると、同じ発想で作れる「小さな道具」が社内のあちこちに見つかります。私たちの実例を挙げると、SNS投稿の本文を投稿前に検査するスクリプト(ルール違反の表現やURLの入れ忘れを機械的に検出して止める)、全リポジトリの1週間の活動を1枚のレポートに集めるスクリプト、公開済み文書の鮮度切れ(確認日が古いもの・期限の過ぎた記述)を洗い出すスクリプト。どれも数十〜数百行の小さなプログラムで、専用SaaSを契約するほどではないが、手作業では絶対に続かない類の仕事です。
共通するのは、**「人間の注意力でやっていたチェックを、機械の仕事に変える」**という方向性です。SaaSのカタログには載っていない、その会社固有の「気をつけていること」こそ、小さなツールの種になります。
費用感も具体的に書いておきます。この種のツール作成をAIに任せた場合、かかるのはAI利用料と人間の要件整理の時間だけです。私たちのポータルの場合、AI利用料は数百円程度、人間の時間は半日でした。月額5,000円のSaaSを1本やめられれば年6万円、それが2〜3本なら年10〜20万円の固定費が消えます。小さな話に見えますが、固定費の削減は毎年効き続けます。
判断基準: 買うか、作らせるか
整理します。判断軸は2つです。
軸1: その業務は自社独自か。どの会社でも同じ業務(会計・給与・メール)は、世の中の標準に合わせた方が安い。自社独自の業務は、市販品だと必ず「合わない部分」が出る。
軸2: 止まったとき・間違えたときの影響はどれくらいか。給与計算が止まると事業が止まる。社内の集計画面が半日止まっても、誰も困らない。
この2軸で4象限に分けると、方針が機械的に決まります。
- 独自性が低い×影響が大きい(基幹) → 大手のサービスを買う
- 独自性が低い×影響が小さい → 買うか、無料ツールで済ませる
- 独自性が高い×影響が小さい(すきま) → AIに作らせる主戦場
- 独自性が高い×影響が大きい → 一番慎重に。内製するなら専門家のレビューを挟む。ここをいきなりAI内製で始めない
もう1つ、内製が正当化される条件があります。その業務が自社の差別化の源泉になっている場合です。他社がやっていない業務のやり方は、市販ツールが存在しません。ここは作るしかなく、作る価値もあります。
AIに作らせる5つの手順
すきま業務をAIに作らせるときの手順です。私たちがポータルを作ったときの実際の進め方をもとにしています。
手順1: 要件を業務の言葉で書く。「ダッシュボードを作って」ではなく、「毎朝、SNS投稿の残り数と承認待ちの件数を1画面で見たい。数字の元はこのファイル群」。プログラムの用語は不要です。何を見たいか、何を減らしたいかを書きます。
参考までに、私たちがポータルを作らせたときの要件は、おおよそ次のような箇条書きでした。
- 毎朝見る画面が欲しい。SNS投稿・動画・記事更新の残り件数、対応が必要な項目、承認待ちの件数を1画面で
- 数字の元は、すでに社内で管理しているテキストファイル群。ポータル側にデータを持たない
- 安全な集計スクリプト3本だけをボタンで実行できるようにする。それ以外の操作はボタンにしない
- 自分のPCの中だけで動くこと。外部への公開・送信は一切しない
- 外部ライブラリを使わない。1ファイルで完結させる
プログラムの知識がなくても書ける内容だと分かると思います。**「何を見たいか」「何をさせないか」**の2つが書けていれば、実装の詳細はAIが埋めます。
手順2: 安全の原則を最初に指定する。ここが一番重要なので、次の節で独立して書きます。
手順3: 小さく作る。最初から全部入りを頼まず、まず1機能で動かします。私たちのポータルも、最初は「数値の一覧表示」だけでした。ボタン実行やTODO管理は、使い始めてから足したものです。
手順4: 説明書(README)もAIに書かせる。何のためのツールで、どう起動して、どこを触ってはいけないか。作った本人(AI)がいちばん正確に書けるタイミング、つまり作った直後に書かせます。これが「作った人しか分からない」問題への対策になります。
手順5: 使いながら直す。内製の最大の利点は、直すのが早いことです。「この数字も足したい」を思いついたその日に、AIに伝えて反映できます。SaaSなら要望フォームに書いて祈るところです。
安全設計: 内製ツールで事故らないための原則
AIがソフトを書けるようになったことで、社内に小さなツールが乱立し、管理されないまま動き続けるリスクも生まれています。いわゆるシャドーIT のAI版です。私たちが自社の内製ツールに必ず入れている原則を共有します。
原則1: 外部に公開しない。社内ツールは自社のPC・ネットワークの中だけで動かします。私たちのポータルは、自分のPCの中からしかアクセスできない設定にしています。ログイン機能を作り込むより、そもそも外から届かない方が安全です。
原則2: できることを許可リストで縛る。ボタンで実行できるのは、事前に決めた安全な処理だけ。送信・公開・支払い・削除のような取り消せない操作は、内製ツールには載せません。そうした操作は人間が判断して実行する領域として分けます。
原則3: 秘密情報を書き込まない。パスワードやAPIキーをツールのコードに直接書かない。これはAIに作らせるときに明示的に指示します。指示しないと、動くことを優先して埋め込んでしまうことがあります。
原則4: ツールの一覧表を作る。社内にどんな内製ツールがあり、誰が使っていて、何のデータを読むのか。1行ずつでよいので一覧にします。列は「ツール名・目的・使う人・読むデータ・最終確認日」の5つで十分です。乱立への対策は、禁止ではなく可視化です。禁止すると現場は隠れて作り(それが本当のシャドーITです)、可視化すると相談してから作るようになります。この一覧表は監視の道具ではなく、「作ってよい。ただし1行書いてから」という許可の道具として運用するのがコツです。
原則5: 捨てられるように作る。凝った作りにせず、依存を増やさず、データは汎用形式(テキスト・CSV)のまま持つ。ツールを捨てても業務データが残る構造にしておけば、失敗しても損失は作った時間だけで済みます。
よくある質問
「プログラマーがいない会社でもできるのか」 できます。ただし条件があります。コードを書くのはAIですが、要件を業務の言葉で説明できる人と、できたものを業務の目で確認できる人は必要です。多くの場合、その業務の担当者本人がこの役を担えます。逆に「AIが作ったから中身は誰も知らない」を放置するのは危険なので、最低限、READMEを読んで何をするツールか説明できる人を社内に1人置いてください。
「ノーコードツールで作るのと何が違うのか」 方向性は同じで、選択肢が増えたと考えるのが正確です。ノーコードツールはそのツールの流儀と料金体系の中で作ります。AI内製は、流儀の制約なしに自社の環境へ合わせて作れて、固定費もかかりません。一方、ノーコードツールには権限管理や履歴などの土台が最初から付いてきます。複数人で使う・業務の変更が頻繁、といった条件ならノーコードツール、1人〜少人数で使う小さな道具ならAI内製、が目安です。
「作ったものが動かなくなったら誰が直すのか」 AIです。エラーの内容をそのままAIに見せて「直して」と伝えるのが、AI内製ツールの保守の基本形です。このときREADMEが効きます。ツールの目的と構造が書いてあれば、作ったときと別のAI・別の人でも直せます。属人化の対策が「詳しい人を増やす」から「文書を作った直後に書かせる」に変わった、と捉えてください。
内製の弱点も正直に書く
よいことばかりではありません。AI内製には固有の弱点があります。
保守は消えない。作るのが速くなっただけで、動かし続ける責任は残ります。OSの更新で動かなくなることもあります。対策は上記の「小さく・依存なく・READMEつき」で、直すのもAIに任せられる状態を保つことです。
品質は指示に依存する。曖昧な要件からは曖昧なツールができます。最初の言語化は人間の仕事です。
大きくしすぎると破綻する。小さなツールが便利だからと機能を足し続けると、いつの間にか「誰も全体を把握していない基幹システム」になります。影響が大きくなってきたら、それは「買う」側に移すサインです。移すときのために効いてくるのが、安全原則の5つ目「データは汎用形式のまま」です。ツール本体は捨てても、テキストやCSVで持っていたデータはそのまま市販サービスへ持ち込めます。内製ツールは「いつか卒業するもの」と最初から考えておくと、大きくしすぎる誘惑にも歯止めがかかります。
まとめ
- 基幹の業務は大手のサービスを買う。集合知・人材・連携・存続の4点で、大きいものほど有利
- 「独自性が高い×影響が小さい」すきま業務が、AI内製の主戦場。私たちは自社の管理画面を2ファイル260行で作らせ、毎日使っている
- 安全設計5原則(公開しない・許可リスト・秘密を書かない・一覧表・捨てられる作り)を最初に指定する
- 大きくなりすぎたら買う側へ移す。内製は「小さいまま」が正解
「自社のあの業務、作らせたら楽になるのでは」と思い当たった方へ。KOIYALでは、内製に向く業務の棚卸し、AIへの要件の伝え方と安全原則の設計、最初の1本を一緒に作る伴走までを支援しています。社内にこの進め方を根付かせたい場合は、実際の自社業務を題材にした研修としても提供できます。お問い合わせからご相談ください。
自分で始めたい方は、まず「毎週やっている手作業の集計」を1つ選んで、この記事の5手順と安全5原則をそのままAIに渡してみてください。