ビジネスツールの自作 ― チャット・業務アプリ制作

作れるようになった、その後の問題

社内向けのチャットボット、部署専用の集計ツール、申請フォーム。従来は情報システム部門への依頼か外部への発注しか手段がなかった領域が、業務側の担当者の手元で完結するようになっています。これは実際に大きな変化です。

シンプル版のシンプル版を読んだ方は、落とし穴までは同じです。この章が足すのは、ノーコードとの組み合わせ・シャドーIT化の防止・引き継ぎ体制の設計・自作か調達かの判断です。

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

自作の流れ

社内向けの小規模なツールであれば、次の順序が標準的です。工程の順番が重要で、逆にすると作り直しになります。

工程4は速い一方、2・3・5・6が実質的な作業です。1と2と3を先に決めておくことが、後戻りを防ぐ唯一の方法です。

問題を1つに絞る

「経費申請を楽にする」は問題設定として広すぎます。「領収書の写真から日付・金額・支払先を抽出して入力欄に埋める」まで絞ると、完成の判定ができます。

絞る基準は、完成したかどうかを他人が判定できるかです。判定できない粒度の目標は、作り続ける状態を招きます。

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

自然言語での依頼から動くものまでが一気に進みます。実際に使ったときに現れる性質を挙げます。

• 画面と基本機能は短時間で形になる ― この段階の速さが期待値を作ります。
• 既存システムとの接続で止まる ― 相手側の仕様はこちらが渡さないと分かりません(第11章)。
• 指示しなかった要素は実装されない ― 認証、入力検証、ログ、費用上限は明示的に頼む必要があります。
• もっともらしい間違いが混ざる ― 存在しない設定項目、社内システムの仕様の推測。実データで確かめるまで気づけません。
• 変更が広範囲に及ぶことがある ― 依頼していないファイルまで整理される場合があります。

ノーコード・ローコードとの組み合わせ

既存の業務自動化ツールにAIの処理を1工程として組み込む形も広がっています。開発をせずに試せる利点があります。

実務上の注意点は3つです。

• 接続先の権限 ― これらのツールは、社内システムやクラウドサービスに広い権限で接続することがあります。付与した権限の一覧を把握してください。
• 費用の見えにくさ ― 実行回数に応じた課金が、ツール側とAI側の両方で発生します。
• 把握されないまま増える ― 部署ごとに独立して作られると、全体像を誰も知らない状態になります(後述)。

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

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

1. 認証がない

接続元が社内に限られることを根拠に、認証を実装しないまま公開されたツールは各所で見つかります。しかしURLを知っていれば誰でも開ける状態は、退職者・業務委託・部署異動後の人もアクセスできることを意味します。人事情報や取引情報を扱うなら、社内向けでも認証は必要です。

2. 入力の検証がない

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

3. 機密情報が意図せず外部に出る

クラウドのAIを呼び出す構成では、どの項目が社外に出るのかを実装のレベルで把握しておく必要があります。文書をまとめて渡して要約させる実装は手早く済みますが、その文書に個人情報が混じっていれば同時に送信されます。必要な部分だけを送る設計が原則です(第6章)。

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

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

5. 誰も全体を把握していない

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

シャドーIT化の防止

情報システム部門が把握していないツールが業務で使われる状態を、シャドーITと呼びます。AI関連では、次の理由で発生しやすくなっています。

• 個人でもサービスを契約できる(クレジットカードで完結する)
• 試作が短時間で作れるため、相談する前に完成する
• 「AI活用の推進」が組織目標になっていると、止められにくい

禁止では止まらない

全面禁止の方針を取ると、把握できない利用が増えるだけになります。実務的に機能する方法は、申請の敷居を下げて把握することです。

1. 軽い申請経路を作る ― 数行の記入で済む形。承認ではなく「登録」として扱います。
2. 登録すれば支援を受けられるようにする ― 権限設計の相談、共通の仕組みの利用、費用の集約(第8章)。
3. 禁止事項だけを明確にする ― 「個人情報を含むデータを未承認のサービスに入力しない」など、具体的な禁止を数項目に絞ります。
4. 棚卸しを定期的に行う ― 年1回、使用しているサービスと自作ツールの一覧を更新します(第10章)。

この設計の要点は、登録することに利益がある状態を作ることです。登録すると制限されるだけなら、登録されません。

引き継ぎと保守体制の設計

自作ツールが業務に組み込まれた後、必ず引き継ぎの問題が発生します。最小限の備えは次のとおりです。

合計で1ページに収まります。この1ページがあるかないかで、引き継ぎの可否が決まります。詳細な設計書は不要です。

もう1つ重要なのは、置き場所を個人の環境にしないことです。コードと記録を共有の場所に置くだけで、引き継ぎの前提が整います。

自作か外部調達かの判断

判断の基準を明確にしておくと、途中で引き返す決定がしやすくなります。

自作に向く条件(すべて満たす場合)

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

自作の範囲を超えている条件(1つでも該当する場合)

• 全社または複数部署で使う
• 個人情報・機密情報を扱う
• 止まると業務が止まる
• 長期間(年単位)使い続ける前提
• 金額の計算や外部への送信を行う

後者に該当する場合、作ること自体は可能でも維持する体制が必要です。この線引きを最初に確認しておくと、「作ってしまったが公開できない」という状態を避けられます。

中間の選択肢

自作と外部調達の間には、実務的な選択肢があります。

• 自作で試して、要件を固めてから調達する ― 要件が定まっていない段階での調達は、仕様変更の費用が高くつきます(第9章)。
• 自作したものを情報システム部門に移管する ― 業務側が作った試作を、正式なツールとして引き取る形。移管の条件(記録、テスト、権限設計)を先に決めておくと成立します。
• 共通の仕組みを中核組織が用意し、業務側が設定で使う ― 社内検索、プロンプトのテンプレート、認証の共通化(第8章)。個別の自作を減らす最も効果的な方法です。

3番目が中長期的には最も効きます。個別の自作が増える背景には、共通の仕組みが用意されていないという原因があることが多いためです。

自作ツールの品質チェック

公開前に確認する項目を一覧にします。第27章のチェックリストにも収録しています。

1. 認証があるか(社内向けでも、扱うデータ次第で必要)
2. 権限の単位が決まっているか(誰が何を見られるか)
3. 入力の検証があるか(想定外の値でも壊れないか)
4. 外部に送信するデータを必要最小限に絞っているか
5. 実データで数十件以上確認したか
6. 失敗したときの動作が決まっているか
7. ログが残るか(入力・出力・エラー)
8. 費用の上限管理があるか(従量課金の場合)
9. 引き継ぎ用の1ページがあるか
10. 共有の場所に置かれているか
11. 止める条件が決まっているか
12. 情報システム部門に登録されているか

12項目のうち、答えが「いいえ」のものが1つでもあれば、それが次にやるべきことです。すべて埋まっていれば、自作ツールとしては十分な水準にあります。