人工知能（AI）
実運用に耐える AI
多くの AI プロジェクトは、印象的なデモと実際に頼れるシステムのあいだで止まってしまいます。私たちはその隙間を埋めることを専門としています。評価、ガードレール、コスト管理、そして試作を製品に変えるための地道な運用設計です。
提供内容
検索・ナレッジ基盤
社内のドキュメント、問い合わせ履歴、契約書、データベースの上にモデルを載せます。回答の良し悪しを論じる前に、検索層が正しい箇所を返しているかを確かめます。
- 公開ベンチマークではなく貴社のコーパスに合わせて調整した、チャンク分割・埋め込み・キーワードとベクトルのハイブリッド検索
- 権限を考慮したインデックス。利用者が直接開けない文書が検索結果に現れることはありません
- 出典の段落まで遡れる引用付きの回答。レビュー担当がその場で裏取りできます
- 基幹システムの更新に追随する増分インデックス更新。一週間遅れの索引になりません
エージェントと業務自動化
ツールを呼び、状態を読み、実際に処理を行う多段構成のシステム。各ステップを境界づけ、観測でき、取り消せる形に設計します。
- ステップごとの明示的なツール契約と権限境界。すべてを開ける鍵を一本持たせません
- 書き込み・支払い・送信・削除を伴う操作には、人による承認ゲートを置きます
- 入力、ツール呼び出し、リトライ、実際にたどった経路までを含む完全な実行トレース
- 提供元の障害、レート制限、そして単純な誤りに備えた確定的なフォールバック
評価・ガードレール・運用
実際の利用者に触れさせてよいかを決める工程であり、多くのプロジェクトが後から抜けていたことに気づく工程です。
- 貴社の実例と失敗事例からつくる、業務特化の評価セット
- プロンプト・モデル・検索設定のあらゆる変更に対する回帰実行。利用者に届く前に行います
- 入出力のフィルタリング、拒否の挙動、個人情報の取り扱いを、審査の場で提示できる形に
- 機能単位のトークンとレイテンシの予算、そしてそれを守るモデルルーティングとキャッシュ
進め方の原則
評価基準から始める
どう採点するかを、つくる前に合意します。採点の基準がなければ「良くなった」は感想にとどまり、変更が効いたのかどうか誰にも判断できません。
基準を満たす最小のモデルを
ベンチマークは上ではなく下へたどります。評価に通る安価なモデルは、同じく通る最上位モデルより良い答えです。
ファインチューニングの前に検索を
品質の問題の多くは、接地（グラウンディング）の問題です。ファインチューニングは維持の負担が大きく、最初に試すべき手段になることはまれです。
誤答を前提に設計する
モデルは必ず誤ります。重要なのは、その誤りを業務フローが捕捉し、影響を封じ込め、対応できる人に見える形にできるかどうかです。
ご一緒する形
2 – 4 週間
AI 適用可能性の評価
データ、業務フロー、制約条件を確認し、自動化する価値があるもの・ないもの、そして運用にかかる費用をご報告します。価値とリスクで順位づけした候補一覧までを含みます。
4 – 8 週間
価値検証（PoV）
実データと実際の評価セットを用いてユースケースを 1 件構築し、現場が日常的に使える場所へデプロイします。成果物はデモ動画ではなく、根拠にもとづく実施可否の判断です。
3 か月以上
本番構築と運用
システム本体、評価基盤、運用ツールまでを構築します。その後も運用・チューニング・新しいモデルへの追随をご一緒します。
取り扱う技術
案件ごとに選定します。どの案件にも当てはめる自社標準スタックは持ちません。お客様のチームがすでに保守されている技術に合わせます。
モデルと推論基盤
特定の提供元に固定しません。モデル選定は評価の結果であり、提供元の切り替えは移行プロジェクトではなく設計に織り込む前提です。
- Claude
- OpenAI
- Gemini
- Llama
- Python
- PyTorch
- FastAPI
- vLLM
- MCP
検索とデータ
ベクトル検索だけで完結することはまれです。多くの場合、埋め込み、キーワード検索、リレーショナルデータベース、そして基幹システムからの変更ストリームを組み合わせます。
- PostgreSQL + pgvector
- Elasticsearch
- Redis
- Kafka
- pandas
- NumPy
- BM25 + hybrid
実行基盤と可観測性
AI 機能もひとつのサービスです。デプロイ、オートスケール、トレース、そして費用に責任を持つ人が必要になります。
- Docker
- Kubernetes
- AWS
- Google Cloud
- OpenTelemetry
- Grafana
- Prometheus
プロジェクトの流れ
1 – 2 週目
定義
ユースケース、利用者、データソース、そして「十分な品質」の定義。評価基準を先に文書化し、合意してから着手します。
2 – 5 週目
接地
データ接続、取り込み、検索。生成の品質を論じる前に、検索の品質を単独で測ります。原因が異なれば対処も異なるためです。
4 – 10 週目
構築
アプリケーション、ガードレール、人が介在する経路。すべての案件と同じ AI-DLC のレビューゲートのもとで実装します。
継続
運用
トレース、変更ごとの評価、リクエスト単位の費用、そして新しいモデルへ移る際の手順書。作り直さずに追随できる状態を保ちます。
お手元に残るもの
- 貴社が保有し、私たちがいなくても再実行できる評価セットと採点基盤
- トレース、機能単位の費用把握、切り戻し経路を備えた稼働システム
- プロンプトとアーキテクチャの判断記録。担当者が入れ替わっても理由が残ります
- モデル更新の手順書。何を再実行し、何を確認してから切り替えるかを明文化します
- プロンプトと検索設定を、品質を静かに壊さずに変更できる状態のエンジニアチーム
この領域でご相談はありますか
課題の輪郭をお聞かせください。私たちが適任かどうか、正直にお答えします。