自分で作れるようになった、その次に来るもの

社内向けのチャットボット、部署専用の集計ツール、申請フォーム。以前は情報システム部門に依頼するか外注するしかなかったものを、開発の専門家でない人が自分で作れるようになりました。これは実際に大きな変化です。

ただし「誰でも作れる」ことは、「誰が作っても安全に使える」ことを意味しません。この章では、自作の流れを追いながら、どの段階で何を決めておく必要があるかを扱います。第4章の内容(動くものと使えるものの差)を前提にします。

自作の基本的な流れ

作るものの規模によりますが、社内向けの小さなツールであれば、次の順序で進むのが標準的です。

  1. 解く問題を1つに絞る ― 「経費申請の入力を楽にする」ではなく、「領収書の写真から日付・金額・支払先を抜き出して入力欄に埋める」まで絞ります。ここが曖昧なままだと、作りながら要件が膨らみます。
  2. 扱うデータの機密度を決める ― 個人情報・取引情報・人事情報が含まれるかを最初に判定します。ここが後から変わると、作り直しになります。
  3. 誰が使うかと権限を決める ― 自分だけ、部署内、全社。見える範囲が変わると、認証の要否が変わります。
  4. 動くものを作る ― ここは速い工程です。
  5. 実データで確かめる ― サンプルではなく実際の記録を数十件流します。ここで想定外が必ず出ます。
  6. 運用の受け皿を決める ― 動かなくなったとき誰が直すのか、いつ捨てるのかを決めます。

作業時間の感覚で言うと、4は短く、2・3・5・6が実質の作業です。この順序を逆にすると、動くものはできるが公開できない、という状態で止まります。

開発エージェントを使った制作の実際

開発エージェント(目的を伝えると、ファイルの作成・コードの実装・修正・テスト実行までを続けて進めるタイプのAI)を使うと、自然言語での依頼から動くものまでが一気に進みます。実際に使うと、次のような性質が見えてきます。

  • 最初の8割は驚くほど速い ― 画面と基本機能は短時間で形になります。
  • 残り2割で手戻りが出る ― 例外処理、既存システムとの接続、権限の扱いなど、こちらが持っている情報を渡さないと進みません。
  • 指示しなかったことは実装されない ― これは第4章で述べたとおりです。認証、入力検証、ログは明示的に頼む必要があります。
  • もっともらしい間違いが混ざる ― 存在しない設定項目、社内システムの仕様の推測。実データで確かめるまで気づけません。
⚠ 危険信号

開発エージェントにファイルの削除・メール送信・外部への送信といった操作を任せる場合は、権限の範囲を先に決めてください。読み取りだけを許す、対象ディレクトリを限定する、送信の前に人が承認する。作業が自律的に進むぶん、誤った操作もそのまま実行されます。何を読み込ませるかも同様です。外部から届いた文書やウェブページの内容をそのまま処理させる設計では、その中に紛れ込んだ指示文をAIが実行してしまう危険があります(第7章の間接型プロンプトインジェクション)。

「誰でも作れる」の落とし穴

自作ツールで実際に起きている問題は、だいたい次の5つに集約されます。

1. 認証がない

社内ネットワークからしか見えないから大丈夫、という判断で認証を省いたツールは珍しくありません。しかしURLを知っていれば誰でも開ける状態は、退職者・業務委託・部署異動後も含めてアクセスできることを意味します。人事情報や取引情報を扱うなら、社内向けでも認証は必要です。

2. 入力の検証がない

想定した形式のデータだけが来る前提で作ると、想定外の入力で誤った結果を返します。数値欄に文字が入る、日付が未来になっている、同じ申請が二重に送られる。実データで確かめる工程を省くと、稼働後に発見されます。

3. 機密情報が外に出る

クラウドのAIを呼び出すツールでは、送信されるデータの範囲を意識する必要があります。「文書全体を送って要約させる」実装は簡単ですが、その文書に個人情報が含まれていれば、それも送信されます。必要な部分だけを送る設計にしてください。

4. 作った人しか直せない

これが最も高い頻度で起きます。仕様書がなく、設定がコード内に直接書かれ、動かし方も本人の手元にしかない。作った人が異動・退職すると、そのツールは触れないまま業務に組み込まれた状態で残ります。

5. 誰も把握していないツールが増える

部署ごとに自作ツールが増えると、全体像を誰も知らない状態になります。同じデータを別々の計算で出す集計が並立し、数字が合わない原因の調査に時間がかかるようになります。

現場のシーン架空の例

朝凪精機では、営業部の月次の数字と経理課の数字が合わず、経理課から「AIでそろえてほしい」という依頼が出ました。三月九日、情報システム課の倉田が調べると、営業部・経理課・第二工場がそれぞれ自作の集計ツールを持っていて、締め日の扱いが3通りに分かれていました。営業部は受注日で月末締め、経理課は請求の二十日締め、第二工場は出荷日で月末締めです。3つとも「正しく」動いていましたが、前提が違っていました。倉田は、画面のいちばん上に「何日締め、何の日付で数えたか」を1行出しておけば、5分で分かった話だと言いました。数字を出すツールを自作する場合は、計算の前提を画面に表示させておくだけで、この種の混乱は減らせます。

この場面は物語之巻 第5話「小野寺くんのツール」に出てきます。

最低限の備え ― 5つの決めごと

大掛かりな体制は必要ありません。自作を始める前に次の5つを決めておくだけで、上の問題の大半は避けられます。

  1. 扱うデータの機密度 ― 個人情報・人事情報・取引情報を含むかを判定し、含む場合はクラウドへ送る範囲を限定する。
  2. アクセスできる人 ― 認証の要否と、権限の単位を決める。
  3. 置き場所と引き継ぎ資料 ― コードと手順書を個人の環境ではなく共有の場所に置く。「動かし方」「変更のしかた」「連絡先」の3点だけでも書いておく。
  4. 止めるときの条件 ― 使われなくなったら止める、担当者がいなくなったら止める、という条件を先に決めておく。
  5. 誰に相談するか ― 情報システム部門に事前に一報を入れる経路を作る。禁止されるのを恐れて隠すと、後の被害が大きくなります。

なお、自作が増える背景には社内の構図があり、リスクの説明が省かれたまま放置されることもあります。その型を確認質問の形で持ち帰るには裏之巻 第7章「罠を見破るための質問リスト・チェックリスト」が使えます。

自作するか、依頼するか

最後に判断軸を置きます。次の条件に当てはまるものは、自作に向いています。

  • 使うのが自分か、少人数のチーム内に限られる
  • 扱うデータに個人情報・人事情報・取引情報が含まれない
  • 止まっても業務が止まらない(手作業に戻せる)
  • 作った本人が変更を続けられる状態にある

逆に、全社で使う、機密情報を扱う、止まると業務が止まる、長期間使い続ける。この条件に入るものは、自作の範囲を超えています。作ること自体は可能でも、維持する体制が必要だからです。この線引きを最初に確認しておくと、途中で引き返す判断がしやすくなります。