Parashar: ドメイン専門性からAIプロダクトを構築
プロダクト戦略 · AIループエンジニアリング · ドメイン→消費者インテリジェンス · 2024–現在
要約
Parasharは複雑な伝統知識ドメインに予測分析を適用するAI消費者プロダクトです。システムは天文位置データ（Swiss Ephemeris）と数千の解釈ルールを組み合わせます — 精密入力と階層的推論が必要な計算集約ドメインです。プロダクト課題は戦略的でした: どの分析体系を優先するか、相互依存ルールを正しく適用するAIループをどう設計するか、密な多次元出力を非専門家が使えるようにするか。これは真の知的関心から生まれたサイドプロジェクトであり、ドメイン専門性がAIプロダクト思考をどう形作るかの実世界テストです。
1. 問題
対象ドメインにはソフトウェアで扱いづらくする三つの特性があります:
ルール複雑性。ドメインはSwiss Ephemerisで計算された天文位置データ由来の数千の相互依存変数で動きます。単一分析は各々ルール・例外・文脈修飾子を持つ複数の分析体系を横断参照します。専門家はこれらの相互作用を扱うのに何年も費やします。
計算強度。完全な分析を手動で行うには惑星位置を分精度で計算し、数十のデータ点に階層的解釈ルールを適用します。専門家は一回に数時間かかることも。天文層は決定的ですが、解釈層は競合体系間の文脈判断を要します。
専門性ゲートキーピング。質の高い分析には熟練実務者を探す必要があります。標準認証がなく品質差が大きく、知識は徒弟制で伝わります。大半の消費者は厳密な分析と表層的作業を区別できません。
機会
天文データが精密で（Swiss Ephemerisが提供）ルールがコード化可能なら、AIは規模で適用できます。プロダクトテーゼ: 精密科学計算とAIルール適用・文脈推論を組み合わせ、専門家級分析へのアクセスを民主化。
2. プロダクト戦略: 何を作るか
システムのスコープ
ドメインには10以上の分析体系があり各々異なる次元をカバーします。全部入れると包括的だが圧倒的、少なすぎると専門家が浅いと見る作業になります。
戦略的問い: 有用で信頼できる分析を生む最小体系カバレッジは？ 古典的v1スコープ — 何を入れるか決めるとき全PMが直面する問題。
アプローチ: 三基準で分析体系を順位付け:
- カバレッジ — この体系が扱うユーザー質問の割合は？
- 計算決定性 — ルールを信頼してエンコードできるか、主観判断が必要か？
- 体系間依存 — 出力が他へ入るか？（はいならインフラであり任意ではない）
三基準すべて高い体系を先に出荷。重い文脈判断が必要な体系は将来反復へフラグ。
AIがすべきこと vs すべきでないこと
ドメインのすべてを自動化すべきではありません。戦略フレームワーク:
AIがすべきこと
- 天文位置計算
- 決定的ルール適用
- 複数体系の横断参照
- データセット横断のパターン識別
AIが（まだ）すべきでないこと
- 曖昧信号にまたがる文脈総合
- 専門家が分かれる判断コール
- 開かれた解釈ナラティブ
- 信頼区間なしの処方的推奨
すべてのAIプロダクトが直面する同じ構築-延期規律 — AIが価値を足す所と偽の確信を生む所を知る。
3. AIループエンジニアリング
核心課題
標準AIプロダクトはデータパターンから学びます。Parasharはルール体系を学ぶ必要があります — 数千の相互依存if-then、階層オーバーライド、文脈重み。AIループは次のために設計されます:
- 精密天文データの取り込み — Swiss Ephemerisが惑星位置・アスペクト・タイミングを分精度で提供。
- ルールカスケード適用 — 複数分析体系が順次実行; 各々次へ入る中間出力を生成。
- 衝突解決 — 二体系が矛盾するとき、加重解決フレームワークがドメイン慣例に従う。
- 階層出力生成 — 一次信号、二次補助分析、三次エッジケースと注意。
エンジニアリング評価基準
ここでの「正しさ」は統計的精度を超えます:
- 位置精度 — 計算がSwiss Ephemerisと分精度で一致
- ルール忠実度 — 各体系のルールをドメイン専門家同様に適用
- 体系重み — 衝突解決が体系階層の専門家合意と一致
- 完全性 — 結論を変える次元を省かずクエリ種別に関連体系をカバー
これら基準はラベル付きデータセットではなくドメイン専門性から来ます。「正しさの姿」を定義する人はドメイン専門家であるべき — 学習データから正しさを近似するMLエンジニアではありません。
4. UX: 複雑さをアクセス可能に
ドメインは密な多次元出力を生みます。完全分析は同時に10以上の次元を覆うことがあります。一度に全部は圧倒し、少なすぎると浅く感じます。
- Level 1 — ヘッドライン信号。支配的発見を明確に。ユーザーが最も知るべきことは？
- Level 2 — 補助分析。ヘッドラインを強化・限定・複雑化する3–4次元。
- Level 3 — 全深度。全体系出力、横断参照、信頼区間、エッジケース — 利用可能だが強制しない。
プロダクト意見: 明確さを既定に、深さを提供。どちらも妥協せず。
5. これが示すプロダクト思考
戦略的優位としてのドメイン専門性
大半のAIプロダクトは出荷できる程度ドメインを学んだチームが作ります。Parasharはこれを反転 — プロダクト戦略者がドメイン専門家。通常AIプロダクトを劣化させる翻訳損失を削ります:
- 仕様-実装ギャップなし。スコープする人がエッジケース・体系相互作用・品質バーを理解。
- 評価基準が実専門性を反映。「正しい出力」は専門家が何を生むか知る人が設定。
- UX優先がドメイン根拠。何を先に出すか、衝突処理、ここでの段階的開示 — 実務に根ざす。
プロダクト戦略 + AIエンジニアリング、MLエンジニアリングではない
役割はプロダクトビジョン、AIループエンジニアリング、システムアーキテクチャ、UX戦略にまたがる — モデル訓練やインフラではない:
| プロダクト + AI戦略（この役割） | MLエンジニアリング（別役割） |
|---|---|
| AIは何をすべきか？ | モデルはどう学ぶか？ |
| 正しい出力とは？ | 正しさに最適化する損失関数は？ |
| ルール衝突はどう解決すべきか？ | モデルは矛盾をどう扱うか？ |
| v1にどの体系を出荷するか？ | 最小実行可能精度は？ |
| 不確実性はどう提示すべきか？ | 信頼度はどう校正されるか？ |
両方必須。本ケースは左列について。
6. 現状
進行中サイドプロジェクト（2024–現在）。プロダクトビジョン定義、分析体系スコープと優先、AIループアーキテクチャ仕様、評価基準確立、UX戦略設計。ドメインへの真の知的関心から構築 — 科学的計算層とルールベース解釈、AIプロダクト戦略の実世界テスト。
7. 主な学び
ドメイン→プロダクト翻訳: AIプロダクトで最も難しいのはAIではなく戦略的スコープ。どのルールをエンコードし、どの体系を延期し、AIが価値を足す所と偽の確信を生む所。エンジニアリングではなくプロダクト決定。
AIループエンジニアリング: AIがルール体系を適用するとき（パターン探索ではない）課題は学習データからルール忠実度へ。評価基準は統計ベンチマークだけでなくドメイン専門性から。
複雑さのアクセス性: 段階的開示はUXパターンだけでなくプロダクト戦略。Level 2・3へ何を送るかが製品を力づけるか圧倒するかを決める。
要点
トレーディング/リスクAIと同じプロダクト判断: 何が決定的で何が解釈的か、ユーザーが全層を監査できないとき何を先に出すか。