カスタムアプリ、API連携、AI業務フロー：最初に何を作るべきか

まず、チームが改善したい業務を一つ選びます。何を入力し、誰が作業し、どのような結果を必要としているかを書き出してください。そのうえで、既存ツールの設定、システム連携、カスタムアプリ、AI業務フローのどれが必要かを判断します。

最初の開発では、少人数で使ってみる、特定の弱点を改善する、または中止するという判断につながることを目指します。以下はスコープの提案例であり、顧客案件の実測結果ではありません。

既存ツールでできることを確認する

開発を依頼する前に、現在のシステムの設定、エクスポート機能、標準連携を試します。業務とアクセス権限の要件を満たせるなら、設定の変更で済む場合もあります。

残った課題を具体的に書きます。「承認済みの注文を別システムへ転記している」なら連携が候補です。「承認待ちの申請が誰にも見えない」なら共有の作業一覧が候補です。どちらも表計算から始まっていても、解決すべき仕事は異なります。

課題： 承認済みの注文を出荷管理システムへ手入力している。

成果物： 二つのシステム間の注文連携、処理状況の記録、失敗した転送を復旧する手段。

受入確認の例： 承認済みのテスト注文が連携先に一件だけ作成される。同じイベントを再送しても注文が増えず、転送失敗は復旧できるよう記録される。

スコープの境界： 対象システム、項目、イベント種別を決める。過去データの移行や別の接続先は別途定義する。

課題： 申請、担当の割り当て、承認がメッセージと表計算に分散している。

成果物： 合意した権限を持つ利用者が、申請の作成、割り当て、確認、出力を行える一覧画面。

受入確認の例： パイロット利用者が合意した操作を完了でき、確認担当者が履歴を見られる。権限のない利用者は承認できない。

スコープの境界： 権限、画面、稼働環境を決める。サンプルデータで動く試作だけでは、本番運用の準備が整ったとは判断しない。

課題： 担当者が届いた文書を読み、確認用の構造化データを作っている。

成果物： 抽出または分類の下書き、参照元の文書、重要な処理の前に人が確認する手順。

受入確認の例： 開発に使わず残した評価用データについて、担当者が付けた正解と出力を比較する。誤りを記録し、情報が足りないケースが確認担当者へ渡ることも調べる。

スコープの境界： 対象形式、言語、データの扱い、評価の限界を決める。モデル自身が示す確信度だけで正しさを判断しない。

手順が分かっている業務は、明示したフローから始めます。自律的な判断は、業務上必要で、その判断を評価できる箇所に絞ります。Anthropicの技術ガイドも、まず最も簡単に機能する方法を試し、必要に応じてエージェントの複雑さを加えることを勧めています。技術ガイドを読む。

当社は、主な失敗時の動作と権限の確認を最初の開発範囲に含めることを勧めます。成功するデモだけでなく、日常業務に合う方法かを判断する材料になるためです。

課題の場所が曖昧： 開発内容を決める前に業務を整理する。

案はあるが結果が不確か： 合意したデータで一つの問いを検証する有償PoCを行う。

検証結果とパイロット利用者がいる： 運用要件も含め、実際に使える最小限のアプリや連携を定義する。

業務責任者、代表的なサンプル、アクセスの準備状況、現在の手順を用意し、不明点は不明と記載してください。AI PoCの1ページ依頼書を使い、実装前に受入条件を合意します。

固定スコープのパッケージを比較すると、判断に合った始め方を選べます。