最初に作るべきカスタムアプリ、API、LLMワークフロー

カスタムソフトウェアは、最初のバージョンが明確なボトルネックを取り除くときに最も説得力を持ちます。小さな社内アプリ、API連携、LLMワークフローは、大きなプラットフォーム刷新より早く証拠を作れます。

問いは「AIで何ができるか」ではありません。「来月までに、どの業務をより速く、安全に、運用しやすくすべきか」です。この問いを採用するだけで、不適切な最初の案件の半分は自動的に外れます。業務責任者が運用指標で測れない案件は、ほぼすべて外れるからです。

最初に向いているテーマ

良い候補には、繰り返される入力、明確な利用者、判断しやすい成果物があります。

バックオフィスの手作業を支える管理画面

CRM、決済ツール、プロダクトDB、スプレッドシートをつなぐAPI連携

サポート、オンボーディング、リサーチ、社内運用向けLLMアシスタント

文書やフォーム入力をアプリや業務フローへ渡す処理

社内文書やチケットを横断する引用付きナレッジ検索

経営、経理、カスタマーサクセス向けのレポート自動化

これらは、ビジネス上の判断につながるソフトウェア課題です。

それぞれに、早期に固定すべき既定アーキテクチャがあります。

管理画面: Next.js(App Router)+ tRPC または REST + Postgres + Auth.js / Clerk によるRBAC。権限・監査ログが本物の要件になった瞬間に、ノーコードの社内ツールビルダーに頼り続ける誘惑は捨てる。

API連携: 外部システムごとに型付き連携層(TypeScript+Zod、またはPython+Pydantic)、加えて冪等なジョブキュー(BullMQ、Sidekiq、Temporal、pgmq)。Webhookは認証必須、イベントIDで重複排除、指数バックオフで再試行。

LLMアシスタント: OpenAI/Anthropicの前段に薄いサービス。プロンプトのバージョン管理、構造化出力スキーマ、応答ログ、テナント別レート制限。ブラウザから直接モデルを呼ばない。

文書受付: OCRアダプタ+抽出モデル+検証ルール+レビューUI(文書自動化の記事を参照)。

ナレッジ検索: ハイブリッド検索(BM25+ベクター)、リランカー、引用厳格生成、アクセス制御済みチャンク。

レポート: 定期抽出 → 変換 → メトリックレイヤ → AI論評 → 承認 → 配布。

すべてのプロジェクトが初日に全スタックを必要とするわけではありません。重要なのは、既定を早く決めて、3週目に再設計しないことです。

初回相談に必要なもの

最初の打ち合わせでは、画面例、サンプルデータ、現在のツール、週あたりの件数、APIアクセスの有無、業務責任者、PoC後に判断したいことがあると早く進みます。

より完全な事前資料リスト:

現行業務の画面キャプチャ3〜5枚(または短いLoom)。

匿名化サンプル20〜50件。

関わるSaaS・社内システム一覧と認証方式(OAuth、APIキー、SSO)。

週次・ピークの処理件数と影響ユーザー数。

業務責任者の氏名、レビュアー/承認者の役割。

既存SLAまたはエラーコスト(「誤転送1件あたりX時間」「請求遅延1件あたりY円」)。

制約条件:データレジデンシー、オンプレ要件、デプロイリージョン、言語要件。

PoC後に下す判断の形:統合、拡張、停止、スコープ変更。

これらが揃っていない場合、構築スプリントより短い準備度診断が適しています。診断は同じリストを書面成果物として作成します。構築キックオフで揃えるより速いことが多いです。

狭く始める理由

狭く始めることで納品リスクが下がり、最初の判断が明確になります。1つのワークフローで信頼を得たら、次のスプリントで認証、権限、連携、本番導入、より広いプロダクト画面へ拡張できます。

もう1つの静かな理由があります。スコープを狭くすると、チームの注意がソフトウェアの「実際に使われるかどうか」を決める運用詳細に向きます。外部APIが落ちたときの再試行挙動、レビュアーキューの空状態、技術者でないユーザーへの信頼度表示の仕方—これらが、会議で勝つデモと、1年後にも同じユーザーで動いているシステムの違いです。狭い最初のスプリントは、その両方を生み出せます。