public-research-business-strategy

公開情報ベースのAI事業戦略リサーチ

目的

Hermes Agentや同種のAIエージェントを中核に、AI導入支援、Managed Private Runner、SaaS、OEM、運用保守などの事業を検討する際に、公開情報だけで検証可能な事業戦略レポートを作る。単なる製品比較ではなく、設立・販売・運営・ガバナンス・競合ポジショニングまで一つの意思決定資料にまとめる。

トリガー

• 「AI導入スタートアップを設立したい」
• 「Hermes AgentをSaaS化したい」
• 「競合製品・競合他社を調査して事業計画にしたい」
• 公開情報だけで市場・価格・競合・運営モデルを調べたい

必須原則

1. 公開情報と推論を分離する。価格・機能・法制度は出典付きの事実、事業案・価格仮説・勝ち筋は推奨/仮説として明示する。
2. 公式資料を優先する。製品機能・価格は公式ページ、会社設立・税務は政府/公的機関、リスクは公的ガイドラインを先に確認する。
3. 会社設立、税務、契約、融資、補助金、法務は専門助言ではないと明記し、専門家レビューを提案する。
4. 汎用AIの機能競争ではなく、顧客業務の成果、運用責任、データ境界、承認・監査を比較軸にする。
5. 失敗した取得を成功と報告しない。許可リストや検索バックエンドで証拠を得られなかった場合は制約として記録し、取得できた一次情報で補完する。
6. 顧客データ・秘密・個人情報・APIキーは公開研究の証拠パケットに入れない。

推奨ワークフロー

1. 調査スコープを固定

最初に以下を決める。

• 対象市場と地域
• 顧客セグメント
• 初期ユースケース
• 比較対象（製品、企業、代替手段）
• 事実調査と事業仮説の境界
• 公開許可ドメイン
• 出力形式と利用者

Hermes/Research Deskでは、public_research、アクティブプロファイル、限定ワークスペース、承認状態を明示する。顧客IDやテナントIDをユーザー入力から受け取って実行主体にしない。

2. Research Deskを先に使う

Research Deskが利用可能なら、次の順序で進める。

1. research_desk_statusでプロファイル、ワークスペース、OpenManus、許可リストを確認。
2. research_desk_planでトピック、対象、ソースドメイン、ワーカー数、出力形式を固定。
3. 返されたplan ID/hashを確認し、人間の承認を得る。
4. research_desk_runはapproved=trueとacknowledge_side_effects=trueを明示して実行。
5. 生成後に証拠、レポート、レシートを確認し、research_desk_exportを別承認で行う。

Research Deskは、公開Web収集をHermes境界で行い、OpenManus workerへはレッドアクト済み証拠を渡す設計とする。workerのブラウザ/Web/MCPアクセスは既定で無効、Hermes LLM合成を主経路とする。

3. 許可リストを検索結果に合わせて設計

許可リストは「見たいサイト」だけでなく、実際の検索バックエンドが返す公式URLのホスト名と整合させる。公式情報を優先しつつ、価格比較・市場動向の補助サイトを使う場合は、一次情報と二次情報をレポート上で分離する。

no allowlisted public sources returned が出た場合:

• 失敗を成功扱いしない。
• エラーをEvidence/制約として保存する。
• 検索結果に出た公式ドメインのみ、必要最小限で許可リストに追加する。
• 許可リスト上限がある場合、対象を優先順位付けして再計画する。
• 再実行しても採用可能な証拠がなければ、Web調査/抽出で取得した一次情報を手動検証版として作成する。

4. 一次情報を並列収集

最低限、次の束を集める。

• 基盤製品: 公式GitHub、公式ドキュメント、プラグイン/メモリ/実行環境資料
• 競合: 公式価格、Enterprise機能、データ保護、デプロイ形態
• 設立: JETRO、法務局/国税庁、e-Tax等
• AI運用: IPA、経産省、総務省等のガイドライン
• 補助的市場情報: 二次情報。ただし一次情報と混ぜない

独立した検索・抽出は並列化する。各主張はURL、ページタイトル、取得日を対応づける。価格と機能は変わるため「調査日時点」と記載する。

5. 事業仮説へ変換

レポートは以下の順で構成する。

1. エグゼクティブサマリー
2. 推奨事業形態とNo-Go領域
3. 顧客課題と初期垂直市場
4. 製品/サービス構成
5. 競合製品・企業比較
6. 収益モデルと価格仮説
7. 設立・契約・ガバナンス論点
8. 運営体制と導入プロセス
9. KPIとユニットエコノミクス
10. 12か月ロードマップ
11. リスクと対策
12. 出典と検証上の制約

Hermes Agentを使う場合、モデル性能の優位性を断言せず、プロファイル分離、承認、監査、メモリ、スキル、Cron、複数モデル、顧客環境内Runner、運用サービスの組み合わせを差別化仮説として評価する。

6. SaaSより先にManaged Private Runnerを検討

初期は、顧客PC/VM内に配置するPrivate Runner + 導入支援 + 月次改善の方が、汎用クラウドSaaSより売りやすい。データ持ち出し、権限、監査、障害対応、モデル/API変更、バックアップを価格の根拠にする。SaaS化は、顧客分離、監査ログ、権限、更新/ロールバック、利用量・費用監視、インシデント対応を標準化してから進める。

7. 成果指標で価格を検証

価格表を先に固定せず、Pilotで以下を計測する。

• 初回価値到達日数
• 削減時間と金額
• 成功率、再試行率、再編集率
• 人間承認率と承認後採用率
• 顧客ごとのモデル/API/運用費
• 月次運用工数
• 継続率、拡張率、紹介率

競合比較テンプレート

比較軸	Hermes/自社案	競合A	競合B
主顧客
主ユースケース
デプロイ	顧客PC/VM、クラウド等
モデル依存
チャネル/連携
メモリ/スキル
承認/監査
SSO/SCIM/管理
価格	調査日時点
差別化仮説
弱点/導入障壁

失敗しやすいパターン

• Research Deskの計画だけで「調査完了」と言う。
• 検索結果が許可リストに入らないのに、推測で証拠を補う。
• 価格比較サイトの数字を公式価格として引用する。
• OSSの機能と自社SaaSの提供機能を同一視する。
• 「データは絶対に漏れない」「完全自動」「人間不要」と表現する。
• 法務・税務・契約の論点を、AIレポートだけで確定する。
• 競合の機能一覧だけで終わり、顧客成果・責任分界・運用費を比較しない。
• 生成レポートの失敗レシートを隠し、成功したように見せる。

検証チェックリスト

• [ ] Research Desk statusがrunnableである
• [ ] Plan ID/hash、承認状態、実行ID、レシートを保存した
• [ ] 許可リストと実際の採用URLが一致する
• [ ] 少なくとも主要主張に公式URLがある
• [ ] 価格に調査日を付けた
• [ ] 事実、推論、仮説、推奨を見出しまたはラベルで分離した
• [ ] 会社設立/税務/契約は専門家確認が必要と記載した
• [ ] 顧客情報、秘密、APIキー、個人情報を含めていない
• [ ] レポートファイルが実際に保存され、読み返せる
• [ ] 失敗した取得・制約・未検証部分を明示した

参照

• セッション固有のResearch Desk実行例・許可リスト問題・公式出典束: references/research-desk-hermes-saas-2026-07.md
• Hermes/OpenClawの一般比較: deepresearch-openclaw-hermes