01AIエンジニアリング
AIエンジニアリング
本番環境で動かすことを前提に設計する生成AI、エージェント、検索基盤。評価、コスト管理、障害時の挙動は、本番リリース後に追加するものではなく最初から組み込みます。
- 生成AIとLLM（大規模言語モデル）の組み込み
- AIエージェントとマルチエージェント構成
- AIコパイロットと業務アシスタント
- RAG（検索拡張生成）と社内ナレッジ基盤
- インテリジェント自動化
- 評価とモニタリング
基本的な考え方
デモ水準ではなく、本番水準へ。
デモは、うまくいってほしいと思っている相手の前で、一度動けば成立します。本番システムはそうはいきません。仕組みに関心のない利用者が、火曜日の午後に、実際の負荷と実際のデータのもとで、権限が正しく効いた状態で使う。しかもコストは事前に見込んだ範囲に収まっている必要があります。
エンジニアリングの大半は、この差のなかにあります。AIを「動かして見せる能力」として扱い、「運用し続けるシステム」として扱わないとき、真っ先に省かれるのがこの部分です。Xcelerates が引き受けるのは、まさにここです。
提供領域
5つの領域。うち1つに、より重心を置いています。
02AIガバナンス
AIガバナンスとアシュアランス
組織内ですでに動いているAIは何か、それによって何が外部に露出しているか、そして次のシステムを本番稼働させる前に何が満たされている必要があるかを明らかにします。
03ソフトウェアエンジニアリング
ソフトウェアエンジニアリング
カスタムシステム、業務アプリケーション、プラットフォーム、システム連携。AIが価値を持つために、その手前で必要になるソフトウェアです。
04クラウドとプラットフォーム
クラウドとプラットフォーム
クラウドアーキテクチャ、デリバリーのパイプライン、信頼性、セキュリティを踏まえたエンジニアリング。つくったものを、引き継ぐ人が運用できる状態にするためです。
05エンジニアリングチーム
エンジニアリングチーム
成果に責任を持つ開発体制。成果を引き受けるチーム、あるいは既存チームに加わるシニア人材。単価表ではありません。
AIエンジニアリングの中身
「AIシステム」と言うとき、何を指しているか。
応用AIで難しいのは、モデルの問題ではありません。事業が依存する仕組みの内側にモデルを置いた瞬間に現れる、ごく普通のエンジニアリングの問題です。
エージェントはプロンプトではありません。ステップ数の上限、ツールの契約、冪等性の設計、そしてモデルが使えない出力を返したときの挙動まで含めて定義された、閉じたループです。
検索（リトリーバル）の仕組みはベクトルデータベースではありません。プロンプトで依頼するのではなく検索の前に判断されるアクセス制御、実際の文書に合わせて選んだチャンク分割、再ランキング、そして返ってきた文書が適切だったかを判断する手段。それらの総体です。
設計すべき対象
- グラウンディング（根拠の明示）
- 回答は根拠となった箇所を引用し、読み手はその引用から元の文書までたどれます。
- アクセス制御
- 呼び出し元の権限に対して、検索の時点で適用します。プロンプトに書かれた権限確認は、権限確認ではありません。
- 評価
- 実際の事例から評価セットを用意します。プロンプトやモデルを変えたとき、議論ではなく計測で判断できるようにするためです。
- コスト
- 本番リリース前にリクエスト単位で見積もり、リリース後は計測します。挙動の変化が請求書ではなく数値として先に見えるようにするためです。
- 障害時の挙動
- 外部呼び出しごとに定義します。タイムアウト、機能を落とした応答、あるいは明示的な拒否。利用者の前で未処理の例外が出ることはありません。
- 人による承認
- 取り消せない操作の手前には必ず人が入ります。システムが見たものと同じ情報を確認し、その判断は記録されます。
検索を根拠とするAIエージェントのアーキテクチャ図です。3つのレーンで構成されています。
リクエスト経路：リクエストは入力ガードを通過します。ここでペイロードを検証し、プロンプトインジェクションを検査します。次にプランナーが2つの経路を選択します。検索経路では、呼び出し元のアクセス権限で絞り込んだうえでキーワード検索とベクトル検索を併用し、結果を再ランキングして上位を返します。recall@k と引用の妥当性はここで計測します。ツール経路では引数をスキーマに対して検証し、冪等性キーを付与します。両経路は合成処理に入り、取得した文書を根拠として引用付きの回答を構成します。
アクション経路：出力チェックが、根拠、スキーマ適合、ポリシーを検証してから外部へ出します。取り消せる操作はそのまま実行に進みます。取り消せない操作は先に人による承認へ回り、承認された場合にのみ実行されます。実行後、応答が返されます。
観測レーン：各段階はトークン数、コスト、レイテンシ、引用した文書、ツールの実行結果を含むトレースを出力します。トレースは評価セットに送られ、プロンプトやモデルを変更した際はリリース前にその評価セットに対して再実行します。
これは一つのアーキテクチャであり、唯一の正解ではありません。どの要素が必要かは、最初の打ち合わせで整理します。
AIエンジニアリングの詳細Xcelerates の進め方
5つの段階と、その都度の判断。
各段階は、読める成果物を残して終わります。そして次に進むかどうかを、前提ではなく選択として判断できる地点で区切ります。最初の段階は、そこで止めても手元に価値が残るように設計しています。
- 01
整理
何をつくるのか、そもそもつくるべきかを見極めます。
産出物
- 文書化されたスコープ
- アーキテクチャの方針
- コストモデル
- 推奨事項
進む、方向を変える、あるいは止める。いずれの場合も手元に成果が残ります。
- 02
設計
システム本体と、外部との境界を設計します。
産出物
- アーキテクチャ決定記録
- インターフェース仕様
- 評価計画
- 合意された完了条件
完了条件はこの段階で合意します。終盤の交渉材料にはしません。
- 03
実装
最初のイテレーションから、実環境で動くソフトウェアを。
産出物
- お客様のアカウント内に置かれるソースとインフラ
- デプロイパイプライン
- テストと変更履歴
進捗は常に見える状態です。最後に成果を披露する場面はありません。
- 04
検証
完了条件を、主張ではなく実証で示します。
産出物
- 合意した評価セットに対する結果
- セキュリティとアクセシビリティの指摘事項
- 予行演習済みのロールバック
本番リリースは日付ではなく、根拠にもとづく判断です。
- 05
運用
引き継ぐ側が実際に運用できる状態で引き渡します。
産出物
- ダッシュボードとアラート
- 引き継ぎドキュメント
継続支援は必要であれば。不要であれば依存は残りません。
入口
「整理」の段階は、AIガバナンスの事前アセスメントとして単独でも実施できます。組織内ですでに動いているAIと、それによって外部に露出しているものを、範囲を区切って評価します。その後 Xcelerates が実装を担当するかどうかにかかわらず、指摘事項はそのまま活用できます。 AIガバナンスとアシュアランス.
Xcelerates を選ぶ理由
4つの理由と、1つの制約。
要件を整理した人間が、そのまま実装する
アーキテクチャの方針を書いたエンジニアが、そのまま実装チームにいます。商談の場で話した内容が、その場にいなかったチームへ引き渡されることはありません。
AIとソフトウェアを、一つの技術領域として扱う
モデルは構成要素の一つです。その周囲には、データモデリング、システム連携、認証、デプロイ、運用が必要になります。それらは別部門の仕事ではありません。
ガバナンスは書類仕事ではなくエンジニアリング
アセスメントの成果は、根拠、深刻度、担当の割り当てです。リスク部門や法務部門へそのまま渡せる形で作成し、次の実装を遅くするのではなく安全にするために使います。
計測は本番稼働後も続く
品質、レイテンシ、コストは実装の一部として計測します。誰も計測していないAIシステムは、誰も説明できないAIシステムです。
そして制約
Xcelerates は同時に抱える案件数を絞っており、要件を整理したエンジニアがそのまま実装を担当します。来月までに大規模な体制が必要な場合、あるいは時間単価の低さが最優先である場合、当社は適任ではありません。その判断は3回目ではなく、最初の打ち合わせでお伝えします。