title: "既存アプリにAI機能を追加する前の設計チェック、入力・出力・権限・ログの決め方" slug: "wwdc26-after-ai-feature-existing-app-design-check-20260608" description: "既存アプリに生成AIの要約や下書き機能を足す前に、入力データの線引き、出力の確認方法、権限分離、ログ保全、課金上限をどう設計するかを実例で解説します。" lead_summary: "既存アプリへAIを足すときは、ボタンを置く前に「何を渡すか」「誰が確かめるか」「どこまで使わせるか」を機能単位で決めておくと、使われない機能や費用超過を避けやすい。 AI機能追加、既存アプリ改修、出力レビュー設計、課金上限とログ保全につながる実務論点を整理する。" date: "2026-06-29" updatedAt: "2026-06-29" category: "AI開発" tags: ["AI機能追加","既存アプリ改修","オンデバイスAI","AI開発","ログ設計","権限設計"] author: "GXO株式会社"
既存アプリにAI機能を追加する前の設計チェック、入力・出力・権限・ログの決め方
スマートフォンや業務端末のOSに、要約や文章補助といった生成AIの機能が標準で載るようになり、自社で運用している既存アプリにも「AIで下書きを出したい」「AIで要約させたい」という要望が社内から上がりやすくなっている。ただ、入力欄の横にAIボタンを一つ足すだけの改修は、想定していなかった情報が外部のモデルに渡ったり、生成された文章の正しさを誰も確かめなかったり、月末になって利用料が跳ね上がったりという形で、後から手戻りを生みやすい。
この記事は、特定の発表を追う速報ではなく、既存アプリへAIを後付けする場面でいつでも使える設計の手順としてまとめている。GXO株式会社がAI開発と業務システムの改修で実際に確認している順番に沿って、追加前に決めておくべき項目を並べる。
先に結論
AI機能を後付けするときに最初に考えるのは見た目ではなく、AIに渡してよい情報の範囲、出力を人が確かめる地点、利用させる量の上限、そして後から追跡できるログの四つである。この四つを画面ごとに決めてから実装に入ると、見た目だけ整っていて現場では使われない機能を作り込む無駄を減らせる。
想定している読者は、すでに動いているWebアプリやモバイルアプリにAIの補助を足したいと考える事業責任者、プロダクト担当、情報システム部門の担当者である。発注のタイミングが来ていなくても、どの画面のどの操作にAIを差し込むのか、その操作がどのデータに触れるのかを先に紙に書き出しておくと、後で見積もりを取るときの前提がぶれにくくなる。
入口としてはAI開発・生成AI活用支援で、現状の棚卸し、要件の言語化、概算費用、実装の順番を別々に切り分けて確認している。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
なぜ後付けほど設計が要るのか
ゼロから作るアプリと違い、既存アプリへの後付けは「すでに動いている業務」を壊さないことが前提になる。現場はその画面で日々の仕事を回しているので、AIが余計な提案を割り込ませたり、保存ボタンの位置が変わったりするだけで、入力ミスや作業の停滞につながる。つまりAIを足す改修ほど、既存の業務動線をどこまで触らないかという守りの設計が重要になる。
もう一つの難しさは、AIが何を入力として受け取り、何を返すのかが画面の見た目から読み取れないことである。利用者には単なる「補助ボタン」に見えても、裏側では顧客情報や社内文書が外部のAPIへ送られているかもしれない。この見えない部分を最初に図にしておかないと、情報の流れを誰も把握しないまま本番に出てしまう。
改修で必ず触れる六つの観点
後付けの相談を受けたとき、GXOでは最初に次の六つを表に書き出してもらっている。
| 観点 | 後付け改修で確かめること |
|---|---|
| 対象画面 | AIを差し込む画面を一つに絞れているか、複数画面に散らしていないか |
| 入力データ | その画面でAIが読む情報に、社外秘や個人情報が混ざらないか |
| 出力の扱い | AIの生成結果をそのまま保存・送信させるか、人の承認を挟むか |
| 権限 | 一般利用者と管理者でAIに許す操作を分けられているか |
| 課金 | 1リクエストあたりの単価と月の上限を見積もれているか |
| 追跡 | 誰がいつどんな入力でどんな出力を得たかを後から再現できるか |
この六つのうち、後付けで最も抜けやすいのが入力データの線引きと課金の上限である。動くものを早く見せたい気持ちが先に立つと、まず画面を作り、データの扱いと費用は後回しになりがちだからである。
渡してよい情報と確認すべき出力
既存アプリへAIを入れる肝は、チャット欄を増やすことではなく、AIが「見てよい情報」と「触れてはいけない情報」を境界線として引くことにある。たとえば問い合わせ対応アプリで返信の下書きをAIに作らせる場合を考える。AIに渡すのは問い合わせ本文と公開済みのFAQまでにとどめ、顧客の与信情報や他社との契約条件は渡さない、という線引きを画面の設計図に書き込んでおく。
出力の扱いも同じ粒度で決める。下書きをAIが作ったとしても、送信ボタンを押すのは必ず人にする、という一手間を残しておけば、誤った金額や事実と異なる案内がそのまま顧客へ飛ぶ事故を防げる。逆に、社内向けの議事録要約のように間違っても影響が小さい用途なら、人の確認を省いて自動保存にしてもよい。重要なのは、用途ごとに人が確かめる地点を変えることで、全部を一律に「人が必ず確認」にすると現場が使わなくなり、全部を「自動」にすると事故が増える。
後付け改修で起きやすい失敗の型
設計を省いて後付けすると、よく似た失敗が繰り返される。一つは、AIボタンは付いたが現場が押さないまま放置される型で、これは既存の業務手順にAIがどう噛むかを決めずに「とりあえず置いた」ときに起きる。もう一つは、便利だからと利用が広がった結果、想定の何倍ものAPI費用が請求される型で、これは1操作あたりの単価と上限を決めていないと避けられない。
三つ目は、AIの誤回答が問題になったときに「いつ誰の操作でその出力が出たのか」を追えず、原因調査が止まる型である。これを防ぐには、入力と出力、実行者、実行時刻をまとめて残すログを最初から組み込んでおく必要がある。後からログを足すのは、すでに本番が動いている分だけ難しくなる。
追加前に踏む五つの手順
- AIを差し込む画面を一つだけ選び、その画面の現状の操作を書き出す
- その操作でAIが読む情報と書き込む情報を、矢印で図にする
- AIに任せてよい判断と、人が必ず確かめる判断を線引きする
- 1リクエストの想定単価から月の上限額を決め、超えたときの挙動を決める
- 小さな試作で誤回答の頻度と実際の費用を測ってから横展開を判断する
この順番で進めると、OSに新機能が載ったというニュースに反応してツールから選び始める状態から、自社の業務と費用と運用から逆算して必要な機能を決める状態へ移れる。GXOが最初の打ち合わせで聞くのも、製品名や流行りの技術ではなく、どの画面のどの作業を、誰のために、いくらの予算で楽にしたいのかという点である。
追加前に手元で確かめる項目
- AIを足したい画面で、現場が本当に困っている作業を一つ言えるか
- その画面でAIが読む情報の中に、社外へ出してはいけないものが混ざらないか
- 生成結果をそのまま使う用途か、人の承認を挟む用途かを区別できているか
- 1操作の単価と月の上限、上限到達時の動きを決めているか
- 入力・出力・実行者・時刻を残すログの置き場が決まっているか
- 試作で測る指標(誤回答率・費用・操作時間)を先に決めているか
ここで答えに詰まる項目が二つ以上あるなら、画面を作り始める前に、要件をそろえる打ち合わせを先に持つほうが結果的に早い。
手をつける入口としてはAI開発・生成AI活用支援がわかりやすい。あわせて確認しておきたい関連ページを下にまとめておく。
相談に進めると早いケース
- AIボタンを置く画面は決めたが、渡してよい情報の範囲が曖昧なまま止まっている
- 生成結果を人が確認すべきか自動でよいか、用途ごとの判断がつかない
- 試作までは作ったが、課金の上限とログの保全をどう組むか決まっていない
- 既存アプリが古く、AIを足すと業務が止まらないか不安がある
既存アプリへのAI追加を一緒に設計しませんか
どの画面に、どのデータを渡し、どこで人が確かめ、いくらの上限で動かすか。AIボタンを置く前の設計図づくりを、現状の棚卸しから実装順序まで段階的に確認します。
最初の打ち合わせでは、営業資料の説明より、対象画面と判断材料の整理を先に進めます。
よくある質問
どの画面から手をつけるか自分たちで決められません
決められなくても問題ない。困っている作業の頻度と、間違ったときの影響の大きさを並べて、頻度が高く影響が小さい作業から試すのが定石である。打ち合わせでは、その並べ替えから一緒に行う。
生成結果を全部人が確認すると現場の負担が増えませんか
そのとおりで、確認をすべて必須にすると現場は使わなくなる。だからこそ用途ごとに確認の有無を変える。金額や対外的な案内に関わる出力だけ承認を挟み、社内向けの下書きは自動にする、といった切り分けを設計段階で決めておく。
AIを足すとセキュリティ面は別で考える必要がありますか
別案件として切り離す必要はない。AIに何を渡すかという線引き自体がデータ持ち出しの設計そのものなので、入力データの範囲を決める作業の中でアクセス権限とログの扱いも一緒に固めるほうが、後から作り直さずに済む。
