社内ツールの作り方：管理画面、承認、スプレッドシートの置き換え

社内ツールを作るには、今つらい思いをしている業務を一つ選びます。多くは、共有のスプレッドシート、メールのやり取り、あるいはデータベースの役割を担っているチャットチャンネルです。それを、適切なフォーム、ステータス付きの一覧、役割ごとの権限、誰が何を変えたかの履歴を備えた小さなアプリに変えます。AI アプリビルダーなら、最初の動くバージョンを半日ほどで作れます。成功の鍵は、範囲を一つの業務に絞り、毎日それを使う人たちと一緒に作ることです。

社内ツールとは何か

社内ツールは、事業を回す地味だけれど欠かせないソフトウェアです。代表的な種類は次のとおりです。

さらに出発点を知りたい場合は、チーム向け社内ツールのアイデア を参照してください。

そもそも作るべきか

一人だけが管理していて、データ量が少なく、誤りの影響も小さければ、スプレッドシートを使い続けてください。次のような兆候があれば、ツールを作る価値があります。

• 人々が互いの変更を上書きする、または、どれが最新のコピーか誰にも分からない
• 一部の人だけに、データの一部だけを見せたり編集させたりする必要がある
• シートの使い方を、一ページの説明書にまとめている
• ステータスの変更で誰かに通知する必要があるのに、よく見逃される
• 監査証跡が必要である。誰がこれを承認し、いつ承認したのか

中間の選択肢もあります。ローコードの社内ツール基盤（Retool、Airtable のインターフェース、Softr など）は、既存のデータの上に部品を組み立てる方法を提供します。データがすでに対応したデータベースやスプレッドシートにあり、ドラッグ＆ドロップで画面を作りたい場合に向いています。AI で作るアプリは、業務が特殊で、チームが必要とする通りの見た目と動きにしたい場合や、コードを自分で所有したい場合に向いています。一般的な判断については、小規模ビジネスにおけるソフトウェアの自作と購入 を参照してください。

画面より先に業務を設計する

プロンプトを書く前に、業務を短い物語として書き出してください。経費承認ツールの例です。

1. 社員が経費を申請する。金額、カテゴリ、日付、説明、レシート写真を入力する。
2. 上司に通知が届き、上司がコメント付きで承認または却下する。
3. 一定額を超える経費には、経理の承認も必要になる。
4. 経理が承認済みの経費を、週次のまとめて支払いとして支払い済みにする。
5. 社員は自分の経費のステータスを確認でき、経理はすべてを見られる。

この物語から、次のものが導き出せます。

• データ: 経費、ユーザー、ロール、承認（誰が、判断、コメント、日付）、添付ファイル。
• ステータス: 申請済み → 上司承認済み → 経理承認済み → 支払い済み、または却下。
• ロール: 社員、上司、経理、管理者。
• ルール: 金額のしきい値、どの役割が各ステータスへ移せるか。
• 画面: 申請フォーム、「自分の経費」、「自分の承認待ち」、経理向けのすべての経費の表、履歴付きの詳細ページ。

業務をこうした言葉で説明すれば、AI は最初から適切なものを作れます。

権限と履歴

社内ツールには、給与、顧客情報、お金といった機微なデータが入ることがよくあります。守るべきルールは二つです。

1. すべての操作で、サーバー側の役割を確認する。 上司が承認 API を直接呼び出して、自分の経費を承認できてはいけません。
2. 履歴を記録する。 各ステータス変更と編集を、誰がいつ行ったかとともに保存します。「誰が変えたのか」という争いの大半が解決し、何かが起きたときに非常に役立ちます。

ログインの方法も決めてください。すでに使っている会社の Google や Microsoft のアカウントでサインインできると便利です。メールとパスワードならどこでも使えます。どちらを選ぶにせよ、サインアップを制限して、チームの人しか入れないようにしてください。

最初のプロンプトの例

社員25人の会社向けの社内経費承認ツールを作ってください。社員は、金額、通貨、カテゴリ（出張、食事、ソフトウェア、備品、その他）、日付、説明、レシート写真のアップロードを入力して経費を申請します。上司には「自分の承認待ち」の一覧が表示され、コメント付きで承認または却下できます。300ドルを超える経費は、さらに経理ロールの人の承認が必要です。経理は、すべての経費の表を見られ、ステータス、人、月で絞り込めます。承認済みの経費を支払い済みに変更できます。すべてのステータス変更は、誰がいつ行ったかとともに記録し、経費の詳細ページにタイムラインとして表示してください。ロールは社員、上司、経理、管理者の4つで、すべての操作をサーバー側で確認してください。データはデータベースに保存し、現実的なサンプルデータを入れてください。シンプルで密度が高く、速い画面にしてください。業務で使うツールであり、宣伝サイトではありません。

構築の手順

1. 主要なテーブルとフォーム。 検索とフィルターがはっきり動くよう、現実的なシードデータを入れておきます。
2. ステータスと遷移。 どの人がどのステータスへ移せるかを含みます。
3. ロールとログイン。チームの人だけに制限します。
4. 各レコードの履歴ログ。
5. 通知。 誰かの対応が必要になったら、メールまたはチャットで知らせます。
6. 既存データの取り込み。 スプレッドシートから移行します。スプレッドシートをアプリに変える方法 で、データの整理と取り込みを解説しています。
7. 全員に広げる前に、二、三人の実際の利用者と一週間パイロット運用する。
8. 決めた日に古い方法を止める。 二つのシステムを並行させると、どちらも信用されなくなります。

人に実際に使ってもらうために

社内ツールは完璧に動いていても、人が古い方法を使い続けるために失敗することがよくあります。

• 利用者と一緒に作る。 新しいバージョンを設計する前に、今その作業を誰かがしているところを観察してください。
• 古い方法より速くする。 申請にメッセージを送るより時間がかかるなら、人は引き続きメッセージを送ります。
• 見た目より情報の密度。 運用担当者は、大きなカードと余白の多い画面より、フィルターの効いた表やキーボードで操作しやすいフォームを好みます。
• 次にすべきことを先頭に。 「自分の承認待ち」を、人が最初に目にするものにしてください。

よくある間違い

• スプレッドシート全体を作り直す。 最もつらい一つの業務だけを移し、残りはしばらくシートに残しておきます。
• 担当者がいない。 公開後の変更と修正に責任を持つ人が必要です。
• 権限を後付けにする。 完成したツールにロールを後から足すのは、最初から設けるより難しくなります。
• 監査証跡を省く。 金銭がなくなった最初のときに、それが必要になります。
• ログインなしで公開 URL に置く。 社内向けのものは、必ずサインインを要求してください。

公開後も運用し続けるために

業務は数か月ごとに変わります。新しい承認の段階、新しいカテゴリ、新しいチームなどです。最初からそれに備えてください。

• 設定はコードではなくテーブルに保存する。 データベースにあるカテゴリ、しきい値、承認者の割り当ては、再構築しなくても管理者が変更できます。
• 変更の要望を一か所に集める。 ツール内の「変更を提案する」リンクがあれば、要望がチャットに散らばるのを防げます。
• 定期的にエクスポートする。 主要なテーブルを CSV でエクスポートしておけば、データが閉じ込められず、月末の集計も簡単になります。
• 変更のたびにテストする。 業務の流れを変えた後は、申請、承認、却下を再び確かめてください。権限のバグは、たいていそこに現れます。

運用コスト

AI で作った社内ツールには、ホスティング、データベース、利用者が書類をアップロードする場合のファイルストレージ、通知用のメールやメッセージングサービスの費用がかかることがあります。自分で所有するツールには、通常は席数ごとのライセンス料はかかりません。これは、アクセスが必要な利用者が多く、たまにしか使わない場合に重要です。継続的なコストは、それを保守する人の時間です。

Mythex で作る

社内ツールは Mythex と相性が良いです。業務の流れを説明すると、エージェントがライブプレビュー上でツールを作り、レコード用に Postgres データベースを、書類や領収書などのアップロード用にファイルストレージを追加します。ドキュメントの 社内ツールのユースケース と 管理画面のユースケース に出発点のプロンプトがあります。同僚は、ワークスペース でツールの構築を手伝え、座席ごとの料金はかかりません。

注意点が二つあります。ツールを使うチームのためのログインは、あなたが作るアプリの一部であり、採用する方法もあなたが選びます。Mythex のアカウントとは別物です。また、アプリ自体には Salesforce、HubSpot、Slack との組み込み連携はありません。それらは各 API を、あなた自身のキーで接続します。出発点となるプロンプトは、承認トラッカー または 社内管理ツール のテンプレートを試してください。主にグラフが必要なら、ダッシュボードの作り方 を参照してください。

よくある質問