本記事に登場する HUMAN_INPUT マーカーとは、AI 執筆 skill が記事本文に残す「ここは人間が後で確定値を埋めるべき」を示すプレースホルダー（形式例: <!-- HUMAN_INPUT: 数値を記入 -->）。

事業ポートフォリオ設計 — AIネイティブ組織土台の上で受託とプロダクトをどう選ぶか

「受託か、プロダクトか」を二者択一の問いとして悩む前に、その手前にある判断がある。それは「事業を実行する側の組織が何を持っているか」だ。

マーケティング・セールス・社内ナレッジ管理・エンジニアリング・セールスアシスタント——業務領域ごとの AI エージェント基盤を先に整備しておけば、受託もプロダクトも、その上に乗る事業選択肢として並走できる。中途半端に受託を始めて組織がリソースに引っ張られると、この基盤整備の機会そのものを逃す。

Yakumo はこの順序——AIネイティブな組織土台を先に作り、その上で事業ポートフォリオを設計する——を創業時の最初の判断として決めた。本記事ではこのフレームを整理し、bateson Booking Engine を「土台の上で展開する事業選択の一例」として扱う。判断フレーム全体は親 pillar 「AIネイティブ組織土台と事業ポートフォリオ — bateson に見る Phase 戦略」 で扱う。

事業を選ぶ前に組織を作る — 順序の意思決定

「受託か、プロダクトか」を議論する前に、もう一つ手前の問いがある。それは「その事業を実行できる組織が今の自分たちにあるか」だ。

AI エージェントを事業の中心に据えた組織とは、マーケティング・セールス・社内ナレッジ管理・エンジニアリング・セールスアシスタントといった業務領域ごとにエージェント基盤が整備された状態を指す。この土台なしに受託を始めると、受託案件そのものに組織リソースが全量引っ張られる。問い合わせ対応・提案書作成・プロジェクト管理などの定型業務を人手でこなしながら、並行して次の事業をゼロから考えるのは構造的に無理がある。

Yakumo の創業時の最初の判断は「この基盤整備を先にやる」だった。受託案件を取れるタイミングで敢えて受託を後回しにし、AIネイティブな組織として動ける土台を先に作った。これは機会損失ではなく、事業の選択肢を後から増やすための先行投資だ。中途半端に受託を始めてリソースを食われると、この基盤整備の機会そのものを逃す。

AIネイティブな組織土台の構成要素

「AIネイティブな組織土台」という言葉は抽象的に響くが、実態は業務領域ごとに問いを立て直したものだ。「この業務は誰が担っているか」「AIエージェントが代替できる部分はどこか」「定型と非定型の境界はどこか」——これを各業務領域で解いた結果として整備されるのが、以下のような基盤群だ。

これらの基盤が整備されると、「受託案件が増えても定型業務がスケールする」「プロダクト開発の時間を作れる」という状態になる。土台なしに受託とプロダクトを並走させようとすると、人手が両方に半端に割かれる。

Yakumo の現在の AI エージェント基盤は、業務領域ごとに 4 つの director を立てる構成だ。セールス、マーケティング、システム開発、ウェブ開発の 4 領域それぞれに方針判断を担う agent を置き、その配下に sub-agent と決定論的な skill が並ぶ。受注前提の提案・見積もり、コンテンツ生成と SEO、内製プロダクトの実装、コーポレートサイトの設計、これらが各 director の責務として分離されている。

土台の上での事業ポートフォリオ — 受託もプロダクトも 1 つの選択

土台が整備されると、「受託かプロダクトか」は二者択一の問いではなくなる。どちらも、同じ基盤の上に乗る事業選択肢の一つだ。

受託（個別顧客への成果物提供）のメリットは即時収益と顧客学習だ。顧客の業務課題を深く理解する機会が得られ、その知見が基盤の改善にも還元される。プロダクト（使用権を継続的に提供するビジネス）のメリットはスケーラビリティと中期資産形成だ。一度作った仕組みは顧客数が増えても限界費用が変わらない。

この 2 つは競合しない。同じ基盤の上に乗っている限り、受託で得た顧客理解はプロダクト設計を精緻にし、プロダクトの完成度は受託提案の説得力を上げる。「受託で蓄積してからプロダクト化する」という単方向の因果ではなく、両者が土台を共有しながら並走する構造だ。

意思決定の実質は「今どちらの事業に力を入れるか」という配分の問いであり、配分を変えられるのは土台があるからだ。土台がない状態では、どちらに集中しても定型業務に人手を取られ続ける。

Yakumo の事業構成は、自前のプロダクトを軸に組み立てている。八雲内で使うために設計した SaaS を外部向けに汎用化し、その操作を AI エージェントが代行することで「業務そのものをサービス化する」AI-BPO 型の事業として展開する設計だ。受託開発とコンサルティングはその外側で、顧客の業務理解と自前の基盤への学習還元を担う位置に置いている。

並走を機能させる判断軸

土台がある前提で受託とプロダクトを並走させるとき、「機能している並走」と「形骸化した並走」を分ける判断軸が 4 つある。

基盤の汎用性: 受託案件への対応が基盤の改善に還元されているか。顧客固有の対応に追われるだけで基盤に反映されないなら、並走は受託の肥大化に過ぎない。

検証フィールドとしての受託: 受託案件が、プロダクトで解こうとしている問題の検証フィールドとして機能しているか。顧客の現場で何が実際に問題かを学ぶ経路として受託を使えているかが、プロダクトの方向精度を決める。

自己調達経路: 受託収益でプロダクト開発を自己調達できるか。外部資本に頼らずプロダクトを育てる経路が確保されているかは、意思決定の自由度に直結する。

意思決定者の確保: プロダクトの優先順位を判断する責任者が明確になっているか。受託は顧客から具体的な依頼が来るが、プロダクトは誰かが意思決定を続けなければ動かない。受託繁忙期にプロダクトの判断が止まらない仕組みが先に必要だ。

bateson の事例 — 土台の上で受託案件を multi-tenant 化する流れ

bateson（Yakumo が src/lib/bateson/ に実装した予約エンジン）は、この「土台の上での事業展開」の具体例として機能する。

Phase A は「Yakumo 自身が使う予約エンジンとして実装する」段階だ。この段階での判断は機能数ではなく構造にある。顧客固有実装の分離・テナント分離を後実装できる設計・外部ベンダーの差し替え可能性・ブランド要素の外部注入——これらを Phase A で意思決定として組み込むことが、「将来 multi-tenant 化できる扉を開けておく」ことに相当する。

Phase B は「外部顧客への提供（multi-tenant 化）」だ。Phase A の構造判断が守られていれば、この移行はリファクタリングではなく拡張として実装できる。移行の判断軸は「次の外部顧客候補が具体的に見えているか」だ。見込みがないまま Phase B 投資をするのはリスクが高い。

Phase C / D は複数テナントへの横展開と、受注 funnel としての機能統合だ。bateson が単体の予約ツールではなく「問い合わせた時点で Yakumo のプロダクトに触れている体験」を作る設計になっているのは、Phase A の段階からこの文脈を持って実装しているからだ。

2026-05 時点で bateson は Phase A のままだ。src/lib/bateson/ の実装は Yakumo 自身の問い合わせフローでのみ動作しており、外部顧客向けのデプロイも公開パッケージ化も行っていない。判断としては「先送り」ではなく「次の外部顧客候補が具体的に見えていない」段階で、Phase A の構造判断（tenantId 全引数化・adapter 分離・cancelToken hash 化）が守られているため Phase B への扉は開いた状態で待機している。

並走時の組織運用

並走を機能させる組織設計の核は「プロダクトの意思決定者を先に決めること」だ。受託は顧客から具体的な依頼が届く。プロダクトは誰かが継続して意思決定しなければ前進しない。繁忙期に受託が優先され続けると、プロダクトは「将来やること」として積み上がり、着手されないまま時間が過ぎる。

これを防ぐ実践的な方法は「週次の最低保証時間をルール化する」ことだ。「受託の状況によらず、週に一定時間はプロダクト開発に使う」という形式でルール化し、例外を設けない運用を続ける。この時間が守られない週は、翌週に繰り越すのではなく、なぜ守れなかったかを記録する。原因が「受託案件の構造的な問題」なら、受注判断の基準を変える必要がある。

もう一つの判断軸は「受託案件を取る基準」だ。土台の改善に還元されない案件、プロダクトの検証フィールドにならない案件を無差別に受けると、並走の旨みがなくなる。受注判断の段階で「この案件が並走にどう貢献するか」を問う習慣が、中期的な事業構造を健全に保つ。

2026-05 時点では深刻な優先順位衝突は経験していない。受託案件が入った時期でもプロダクト（自社基盤と bateson）の開発を上位に置く運用を続けており、受託の繁忙でプロダクトの判断が止まる状況は発生していない。これは「プロダクトを優先する」という意思決定があらかじめ設定されていたことが大きく、案件が増えた局面で改めて判断を迫られる構造になっていない。

判断チェックリスト

「受託とプロダクトをどう選ぶか」を問う前に、チェックすべき前提条件を整理する。

まとめ

事業選択の最上流の問いは「受託かプロダクトか」ではなく「その事業を実行できる組織土台が先にあるか」だ。土台がなければ、どちらの事業選択も人手に依存した非スケールな実行になる。土台があれば、受託もプロダクトも、同じ基盤の上に乗る並走可能な事業ポートフォリオとして設計できる。

bateson は「土台がある前提で Phase 展開する」具体例だ。

2026-05 時点で bateson の Phase A は完了している。src/lib/bateson/ には予約エンジンとして必要な機能が実装され、顧客固有実装の分離・テナント分離を後実装できる adapter 設計・Google Calendar や Gmail を含む外部ベンダーの差し替え可能性・ブランド要素のテンプレート注入の 4 原則がすべて反映されている。Yakumo の問い合わせフローで実運用中だ。

Phase A の構造判断が守られていれば Phase B への扉は開いている。扉が開いているかを確認し、外部顧客候補が見えたタイミングで Phase B を判断する——この順序が崩れると、multi-tenant 化は「作り直し」として大きなコストになる。

ただし Yakumo 自身は 2026-05 時点で「週次 X 時間」のような明示的なルールは制度化していない。プロダクト開発を最上位に置く意思決定で運用が成立しているため、定量ルールが必要になる局面がまだ来ていない、というのが実態だ。受託の比率が上がる、もしくは Phase B トリガーが見えて意思決定の負荷が増える段階で、初めて時間ルールが必要になると想定している。

並走する組織を先に設計してから事業を選ぶ、というフレームの全体像は 「AIネイティブ組織土台と事業ポートフォリオ — bateson に見る Phase 戦略」 で扱っている。エンジンの技術実装は 「Booking Engine を自作する設計戦略」 を参照。