AI時代のWEB業務アプリの話をしよう、システムをいかに人に近づけるか

AI時代のWEB業務アプリの話をしよう、システムをいかに人に近づけるか

はい、どうもこんにちは佐藤です!

最近 X でも「AI が業務を変える」という話、毎日のように流れてきますよね。

私は SI の現場に長くいる人間なんですが……、肌感として、システムへの要件が明らかに変わってきていると感じています。

「何かが変わっている」という感覚はあるのに、その変化の正体が言語化できていない。そんなもやもやを抱えているエンジニアや事業担当者の方、多いんじゃないでしょうか。

その変化の正体はなんなのか、そしてこれからの業務アプリはどこへ向かうのか。現場目線でまとめてみますね!


なぜ業務アプリの要件が変わっているのか

変化の背景には、2 つの大きな力があると考えています。

ひとつはビジネスの複雑化です。グローバル化・規制の多様化・サービスの高度化によって、業務のルールは年々複雑になっています。10 年前の仕様書と今の仕様書を見比べると、そのボリュームの差に驚くでしょう。

もうひとつは優秀な人材の採用難易度の上昇。複雑な業務を人間が全部理解して処理するには、相当な熟練者が必要です。でも、そういう人材はどこでも引っ張りだこ。確保できる保証はありません。

この 2 つの圧力が重なって、「人間にやらせていた仕事をシステムに移していく」という流れが加速しています。業務アプリが人間に近づいてきているのです。


2000年〜2015年:テーブルを人間が埋める時代

この時代の業務アプリを一言で表すなら、**「Excel をブラウザで動かしたもの」**です。

graph LR
    A[業務担当者\n業務コンテキスト保持] -->|値を判断して手入力| B[業務アプリ\nテーブル表示]
    B <--> C[DB]
    style A fill:#fffde7,stroke:#f9a825
    style B fill:#e3f2fd,stroke:#1565c0
    style C fill:#e8f5e9,stroke:#2e7d32

テーブルの全カラムを画面に並べて、人間が 1 行ずつデータを入れていく。「このタイミングでこのカラムをこの値に変えて」という業務判断は、すべて担当者の頭の中にありました。

当時は「データ入力のバイト」という仕事が普通に存在していましたよね? それだけ、人手によるデータ変換の需要があったわけです。

言い換えると、この時代のシステムはデータの入れ物に徹していました。業務のコンテキストを理解してデータに変換する役割は、まるごと人間が担っていたのです。データの整合性も同様です。「あ、このレコードを変えたら、あっちのレコードも変えないといけない」という気づきは、担当者の経験と知識から来ていました。


2015年〜2025年:ロールが細分化され、コンテキストが濃縮される

この時代になると、システムが業務の一部を引き受け始めます。

具体例を上げると OCR の発達でしょうか? 紙や画像からデータを自動で読み取れるようになり、「人間が値を見て手で打ち込む」というプロセスが省かれていきました。

graph LR
    A[優秀な担当者\n業務コンテキスト保持] -->|指示・例外処理| B[業務アプリ\nユースケース定義]
    D[オペレータ] -->|決まった操作のみ| B
    E[OCR・外部連携] -->|自動データ入力| B
    B <--> C[DB]
    style A fill:#fffde7,stroke:#f9a825
    style B fill:#e3f2fd,stroke:#1565c0
    style C fill:#e8f5e9,stroke:#2e7d32
    style D fill:#fce4ec,stroke:#c62828
    style E fill:#f3e5f5,stroke:#6a1b9a

システムは「このロールはこのユースケースを実行できる」という設計になり、それぞれのロールが何をできるかを細かく定義するようになっていきます。

その結果、何が起きたでしょうか。

業務を細分化してオペレータに渡せるようになったぶん、業務のコンテキスト全体を理解しているのは、ごく一握りの優秀な人物だけになっていったのです。その他の人はシステムの指示に従うオペレータです。

コンテキストは人からシステムへ、徐々に移転が始まっていました。でもまだ、業務の本質的な判断は人間が握っていました。

この時代に、ワークフローアプリが流行ったのも納得です。


2025年〜:AI がコンテキストを受け取る時代へ

では、AI が発達したこれからはどうなるでしょうか。

私の予測は、「部下に指示を出すように、人間がシステムに語りかける」UI に変わっていくというものです。

graph TD
    A[担当者\n音声・チャットで指示] -->|自然言語| B[AI エージェント]
    B -->|コンテキスト解釈・ツール選択| C[業務ロジック API]
    C -->|データ操作| D[DB / 外部システム]
    B -->|結果サマリを報告| A
    A -->|承認 or 差し戻し| B
    style A fill:#fffde7,stroke:#f9a825
    style B fill:#fce4ec,stroke:#ad1457
    style C fill:#e3f2fd,stroke:#1565c0
    style D fill:#e8f5e9,stroke:#2e7d32

各項目を 1 つひとつ入力するフォームではなく、「○○ の案件、先月と同じ条件で見積もりを出しておいて」とチャットや音声で伝えるだけで処理が走る。

担当者は部下の仕事を確認するように、結果を見て承認するだけです。UI はチャット画面や音声インターフェースへとシフトしていきます。

コンテキストをシステムが受け取り、何をすべきかを判断し、実行する。業務アプリは「人間の道具」から、「人間の同僚」へと変わっていくのです。


3 つの時代の技術を統合する

これは単純に「AI を乗っけたらいい」という話ではありません。各時代の技術の積み上げが必要なのです。

flowchart TB
    subgraph ERA1["2000年代:データ管理の技術"]
        T1[RDB 設計]
        T2[トランザクション制御]
        T3[データ整合性の保証]
    end
    subgraph ERA2["2015年代:ユースケースの技術"]
        T4[ロールベースアクセス制御]
        T5[ワークフローエンジン]
        T6[API 設計]
    end
    subgraph ERA3["2025年〜:AI エージェントの技術"]
        T7[自然言語処理]
        T8[ツール呼び出し設計]
        T9[コンテキスト管理]
    end
    ERA1 --> ERA2 --> ERA3

AI エージェントに「このロールだから、このデータ範囲だけ見て、この処理を実行して」と指示できるのは、ロールとユースケースが正確に設計されているからです。2015 年代の技術なしには成立しません。

また、AI が操作するデータの整合性を保つのは、2000 年代から積み上げてきた RDB とトランザクション設計です。ここがぐらついていると、AI がどれだけ高精度でも、データは壊れます。

一長一短でできることではありません。3 つの時代の技術を、きちんと統合していく必要があるのです。


AI にコンテキストを持たせすぎてはいけない

ここで、重要な設計の話をしておきましょう。

「AI が業務を理解するなら、すべてのコンテキストを AI に持たせればいい」と考えるのは危険です。

理由は 2 つあります。

コストの問題。 AI のコンテキストウィンドウに大量の情報を詰め込むと、API コストが跳ね上がります。会話のたびに業務仕様書を全部読み込ませるようなことをすれば、あっという間に費用が膨らんでしまいます。

ハルシネーションの問題。 AI はコンテキストが長くなるほど、事実でない情報を生成するリスクが増します。「なんとなくそれっぽいこと」を返してくる確率が上がるのです。

では、どう設計するか。

graph LR
    A[AI エージェント\n薄いコンテキスト] -->|ツール呼び出し| B[承認チェック API]
    A -->|ツール呼び出し| C[見積もり生成 API]
    A -->|ツール呼び出し| D[顧客情報取得 API]
    B --> E[ロール・権限テーブル]
    C --> F[業務ロジック]
    D --> G[顧客 DB]
    style A fill:#fce4ec,stroke:#ad1457
    style B fill:#e3f2fd,stroke:#1565c0
    style C fill:#e3f2fd,stroke:#1565c0
    style D fill:#e3f2fd,stroke:#1565c0

AI はコンテキストを持つのではなく、ツールを呼び出す存在として設計する。

「このロールはこの API を叩いていい」という権限設計を API レベルで持ち、AI はそれを呼び出すだけにします。判断のルールはシステム側に閉じ込めることで、AI のブレを最小化できますよね。

AI を優秀な司令塔として使いながら、業務ルールの番人はシステムが担う。この役割分担が、堅牢な AI 業務アプリの鍵です。


まとめ

というわけで、AI 時代の業務アプリは「部下に指示を出す感覚で使うものになる」よ! って話でした!

あ。正確には、AI にコンテキストを丸投げするのではなく、ツールとして使いこなす設計が求められるって感じですねっ。

データ管理・ユースケース設計・AI エージェント設計。この 3 つの技術を統合できる会社こそが、AI 時代の業務アプリを作れます。逆に言えば、「AI を乗っけるだけ」では本質的な変革は起きないのです。

弊社では、チャット UI と AI エージェントの開発に力を入れています。2000 年代からの技術の積み上げと、最新の AI 技術を組み合わせて、あなたの業務を次のステージへ引き上げるお手伝いができます。

AI による DX の推進、ぜひ弊社に託してみてください!

この記事をシェアする