開発バックログ（issue一覧）

この企画を進めるための着手単位のタスクです。リサーチ→企画→技術検証→MVP開発→提案資料作成までをカバーします。GitLabリポジトリの backlog/ に各issueのMarkdownを格納しており、APIトークン更新後にGitLab issueへ一括起票できます。

一覧

#	タイトル	優先度	種別	マイルストーン
01	[調査] 船舶管理会社の業務フローと時間・コストのヒートマップ作成	P0	research	Phase 1: 調査・要件定義
02	[調査] 既存製品・競合の比較分析(日本語UI/国内法令/オフライン耐性/価格)	P0	research	Phase 1: 調査・要件定義
03	[調査] 法令・規制要件と証書/帳票/報告義務の一覧化	P0	research, docs	Phase 1: 調査・要件定義
04	[調査] 内航の通信制約とオフライン/低帯域アーキ方針の確定	P0	research, infra	Phase 1: 調査・要件定義
05	[企画] ターゲットユースケース選定と Go/No-Go 判断	P0	design, research	Phase 1: 調査・要件定義
06	[企画] AIガバナンス・非機能要件定義(出典/監査ログ/人間承認/PII)	P0	design, docs	Phase 1: 調査・要件定義
07	[技術検証] 検証型RAG(出典付き・回答拒否・信頼度バッジ)のプロトタイプ	P0	dev, research	Phase 2: 技術検証・PoC
08	[技術検証] 海事ナレッジベース構築パイプライン(日本語マニュアル/規制のOCR・構造化)	P1	dev, infra	Phase 2: 技術検証・PoC
09	[技術検証] ノンレポート/労務記録の自動生成PoC(船員法の労働時間集計対応)	P0	dev, research	Phase 2: 技術検証・PoC
10	[技術検証] オフライン/エッジ推論の動作検証とベンチマーク	P1	infra, dev, research	Phase 2: 技術検証・PoC
11	[技術検証] 評価基準とベンチマークデータセットの整備	P1	research, dev	Phase 2: 技術検証・PoC
12	[MVP開発] 船内エッジアプリ+陸上管理コンソールの基盤構築	P0	dev, infra	Phase 3: MVP開発
13	[MVP開発] 多言語船員向け業務チャットボット+報告自動生成	P0	dev	Phase 3: MVP開発
14	[MVP開発] 規制Q&A/PSC受検チェックリスト生成(人間レビュー前提)	P1	dev	Phase 3: MVP開発
15	[MVP開発] AIガバナンス基盤(監査ログ・出典トレーサビリティ・PII保護・改ざん検知)	P0	dev, infra	Phase 3: MVP開発
16	[MVP開発] パイロット導入・効果測定(1社・1〜数隻)	P0	docs, dev	Phase 3: MVP開発
17	[提案] 提案資料・ROIモデルの作成	P0	docs	Phase 4: 提案・展開
18	[提案] 船級承認・コンプライアンス対応ロードマップ作成	P1	docs, research	Phase 4: 提案・展開
19	[提案] JSA・業界団体・補助金チャネル開拓と横展開計画	P2	docs, research	Phase 4: 提案・展開

Phase 1: 調査・要件定義

#01 [調査] 船舶管理会社の業務フローと時間・コストのヒートマップ作成

P0 research

背景

船舶管理(技術管理/船員管理/調達/運航/PSC対応)は労働集約・書類集約で、ノンレポート手集計(毎朝数時間)、在庫照合(業界全体で年約1,200万人時、精度約20%)、証書/休息時間のExcel管理など、時間とコストが特定業務に集中している。どこを攻めるかを一次情報で確定する必要がある。

目的

船舶管理会社/船員の業務フローを可視化し、AIで削減効果が最大の業務領域を特定する。

タスク

• [ ] 技術管理・船員管理・調達/在庫・運航・PSC受検・労務管理の業務フロー図を作成
• [ ] 各業務の所要時間・頻度・担当(船員/陸上)・手段(紙/FAX/Excel/SaaS)を棚卸し
• [ ] 国交省一次資料(内航海運の現状と課題、内航海運と船舶管理会社の現状)を読み込み定量データを抽出
• [ ] 可能なら2〜3社へのヒアリング/アンケートで現場の主訴を裏取り
• [ ] 時間・コストのヒートマップとして優先攻略領域を3点に集約

受け入れ条件

• 業務フロー図と時間/コストヒートマップがドキュメント化されている
• 出典(国交省PDF等)が各データに紐づいている
• 攻略候補の業務領域が根拠付きで3点に絞られている

#02 [調査] 既存製品・競合の比較分析(日本語UI/国内法令/オフライン耐性/価格)

P0 research

背景

海事AI/SaaSはノンレポート自動化・配乗労務・規制Q&A・予知保全・海事LLMの各領域で活発。OneOcean/Greywing(SeaGPT)/Full Fathom AI/MariApps OceanAI/AI番頭(JDSC×東洋船舶)/TRANS-Crew/Crewlog/MARITIME 7 等が存在するが、海外勢は日本語UI・国内法令(船員法・内航要件)・国内サポート・オフライン耐性に弱い。

目的

競合のポジショニングと空白地帯を把握し、自社の差別化軸(日本語ネイティブ・オフライン/低帯域・検証型RAG・伴走支援)を確定する。

タスク

• [ ] 主要製品を機能/対応言語/国内法令対応/オフライン耐性/価格/ターゲットで比較表化
• [ ] 検証型RAG(出典付き・回答拒否・信頼度バッジ)の実装有無を整理(Full Fathom AI等)
• [ ] 内航向け配乗労務SaaS(TRANS-Crew/Crewlog/Aisea Crew/MARITIME 7)の機能ギャップを抽出
• [ ] 空白地帯(差別化できる機会)を明文化

受け入れ条件

• 8製品以上を網羅した比較表が完成している
• 各社の出典URLが付与されている
• 自社の差別化軸が3点以上、根拠付きで言語化されている

#03 [調査] 法令・規制要件と証書/帳票/報告義務の一覧化

P0 research docs

背景

海事規制はIMO条約(SOLAS/MARPOL/STCW/MLC)+船級証書+国内法令(船員法/内航海運業法)が多層に重なり、証書管理・帳票記録・報告義務が膨大。2022年4月から船員の労働時間把握が義務化、MARPOL電子記録簿(MEPC.312(74))・IMO MASS Code(2026年採択)・EU AI Act(自律船AIを高リスク扱い)など規制とAIの接点も動いている。

目的

製品が対応すべき規制要件・証書・帳票・報告義務を網羅し、AI出力に課される制約(監査証跡・改ざん検知・旗国承認・人間最終責任)を要件化する。

タスク

• [ ] 船員法/内航海運業法/MLC/STCW/SOLAS/MARPOL ERBの要求事項を整理
• [ ] 証書・帳票・報告義務(有効期限・更新サイクル・船内保持/掲示要件)を一覧化
• [ ] PSC(Tokyo/Paris MoU)頻出不具合(ISM/防火/救命/MLC)とディテンション要件を整理
• [ ] IMO MASS Code・EU AI Act・MEPC.312(74)がAI出力に課す制約を抽出
• [ ] 規制改正の追随方法(クロール対象ソース・更新頻度)を設計メモ化

受け入れ条件

• 規制要件一覧と証書/帳票管理要件がドキュメント化されている
• AI出力に課す非機能制約(監査ログ/出典/人間承認/PII非保持)が箇条書きで明示されている
• 各要件に一次出典が紐づいている

#04 [調査] 内航の通信制約とオフライン/低帯域アーキ方針の確定

P0 research infra

背景

船上の衛星通信(VSAT/Inmarsat)は低帯域・高遅延・間欠的で、Starlinkも全船未普及。クラウドLLM常時接続前提のサービスは航海中に実用にならない。Full Fathom AIは27MB単一バイナリで全推論を船内完結(GPU不要/16GB RAM)、SmartSeas型は船内ローカル推論+低帯域メタデータ同期を採る。日本籍船のStarlink公海利用は2024年2月に解禁済み。

目的

船内ハード・通信前提を確定し、オフライン/低帯域でも動くアーキテクチャ方針(エッジ推論+後同期)を決める。

タスク

• [ ] 想定する船内ハードスペック(CPU/RAM/ストレージ、GPU有無)の現実値を調査
• [ ] 通信手段別(VSAT/Inmarsat/Starlink)の帯域・コスト・可用性を整理
• [ ] エッジ推論モデル候補(サイズ・量子化・日本語性能)を比較
• [ ] 同期方式(メタデータのみ低帯域同期、ナレッジ/モデルの定期更新)を設計
• [ ] 日本籍船のStarlink規制動向(2024年解禁)を確認

受け入れ条件

• オフライン/低帯域アーキ方針書が完成している
• 想定ハード・通信前提が数値で明記されている
• エッジ推論モデルの候補と選定基準が示されている

#05 [企画] ターゲットユースケース選定と Go/No-Go 判断

P0 design research

背景

調査(課題ヒートマップ・競合・規制・通信制約)を踏まえ、限られたリソースで勝てるユースケースを1〜2本に絞る必要がある。有力候補はノンレポート/労務記録自動化、多言語規制Q&A(検証型RAG)、PSC受検支援、予知保全。

目的

課題×AI機会の優先度マトリクスでMVPの対象ユースケースを確定し、経営/ステークホルダーのGo/No-Go判断に資する。

タスク

• [ ] 課題インパクト×実現容易性×差別化×規制リスクで候補ユースケースをスコアリング
• [ ] 各候補のターゲット顧客(外航/内航、規模)とバリュープロポジションを記述
• [ ] MVPスコープ(コア1本+補完1本)を提案
• [ ] 想定ROI(報告時間削減率・配乗計画工数削減・PSC指摘削減など先行事例ベンチ)を試算
• [ ] Go/No-Go判断資料としてまとめる

受け入れ条件

• 優先度マトリクスとユースケース選定書が完成している
• MVPスコープが1〜2ユースケースに絞られている
• ROI試算が先行事例(商船三井7割削減/SIMS3等)を根拠に提示されている

#06 [企画] AIガバナンス・非機能要件定義(出典/監査ログ/人間承認/PII)

P0 design docs

背景

規制業務へのLLM適用はハルシネーション・責任所在不明・監査証跡要件・人間最終責任(MASS Codeでも船長が常時責任)という強い制約を受ける。EU AI ActやMEPC.312(74)はデータガバナンス・自動ログ・人間監督・改ざん検知を要求。安全クリティカル領域では出典検証・回答拒否・PII非保持が前提。

目的

製品全体を貫くAIガバナンス・非機能要件を定義し、設計・実装の前提として固定する。

タスク

• [ ] 出典トレーサビリティ要件(ページ/章単位引用、根拠不足時の回答拒否、信頼度バッジ)を定義
• [ ] 人間承認ワークフロー(AIは下書き、最終判断は人間)の標準フローを設計
• [ ] 監査ログ・改ざん検知(SHA-256等)・記録保持要件を定義
• [ ] PII非保持/船内データ分離/外部API送信ポリシーを定義
• [ ] EU AI Act高リスク要件・MEPC.312(74)との対応マッピングを作成

受け入れ条件

• AIガバナンス・非機能要件定義書が完成している
• 各要件が規制(EU AI Act/MEPC.312(74)/MASS Code)に紐づいている
• 設計フェーズで参照できるチェックリスト化がされている

Phase 2: 技術検証・PoC

#07 [技術検証] 検証型RAG(出典付き・回答拒否・信頼度バッジ)のプロトタイプ

P0 dev research

背景

海事の安全クリティカル領域ではハルシネーションが重大リスク。Full Fathom AI型の検証型RAG(BM25+ベクトルのハイブリッド検索、ニューラル再ランク、権威階層 Vessel>SMS>Fleet>Regulation>Reference、引用検証、根拠不足時の回答拒否、信頼度バッジ)が安全設計の参照モデルとなる。

目的

ハルシネーションを抑制し出典をページ単位で返す検証型RAGをプロトタイプ化し、安全クリティカル領域での実用可否を確認する。

タスク

• [ ] BM25キーワード検索+ベクトル検索のハイブリッド(Reciprocal Rank Fusion)を実装
• [ ] 権威階層・ニューラル再ランクを組み込み
• [ ] 引用検証と十分性オートレーター(根拠不足時の回答拒否)を実装
• [ ] 信頼度バッジ(高/中/低)の表示を実装
• [ ] クルー用語→規制用語の語彙拡張を実装
• [ ] Claude等LLMをバックエンドにした検証パイプラインを構築

受け入れ条件

• 出典付き回答と根拠不足時の回答拒否が動作する
• ハルシネーション率・出典正確性が計測可能
• 信頼度バッジが回答に付与される

#08 [技術検証] 海事ナレッジベース構築パイプライン(日本語マニュアル/規制のOCR・構造化)

P1 dev infra

背景

現場マニュアル・安全手順・社内規程は日本語の紙/Word中心で体系化されておらず、RAGに投入できる高品質ナレッジ構築自体に前処理コストがかかる。証書・帳票はOCR+LLMで有効期限/発行体/対象annexを構造化抽出できる。

目的

散在する日本語マニュアル・規制文書・社内手順をRAG用に取り込む構築パイプラインを検証する。

タスク

• [ ] PDF/Word/スキャン文書のOCR(手書き・FAX・劣化文書含む)処理を検証
• [ ] チャンク分割・メタデータ付与(出典/版/権威階層)を実装
• [ ] 証書・帳票からの構造化抽出(有効期限/発行体/対象)を検証
• [ ] ベクトルストアへのインデックス化と更新フローを構築
• [ ] 前処理コスト(人手介在量)を計測しオンボーディング工数を見積もる

受け入れ条件

• サンプル文書群でナレッジベースが構築できる
• 構造化抽出の精度が計測されている
• 顧客オンボーディング時の前処理工数が見積もられている

#09 [技術検証] ノンレポート/労務記録の自動生成PoC(船員法の労働時間集計対応)

P0 dev research

背景

ノンレポート等の手作業集計が乗組員の午前中数時間を奪い、手入力ゆえ精度が低い。2022年4月から船員法で労働時間把握(客観的方法)が義務化され記録負担が増加。音声・スマホ入力+AI自動生成で多重転記を排除できる余地が大きい(大東汽船はノーコード35アプリで作成送信時間を半減)。

目的

船員が音声/スマホで口頭報告するだけで日報・点検記録・労務記録のドラフトを生成し、労働時間を自動集計するPoCを作る。

タスク

• [ ] 音声・スマホ入力UIのプロトタイプ作成
• [ ] 入力→ノンレポート/日誌ドラフト生成(AIS/センサー連携は将来拡張として設計)
• [ ] 船員法の1日8時間/週40時間ルールに沿った労働時間自動集計
• [ ] 帳票出力(国交省様式・社内様式へのマッピング)
• [ ] オフライン入力→後同期の動作確認

受け入れ条件

• 口頭/手入力から帳票ドラフトが自動生成される
• 労働時間集計が船員法ルールに沿って計算される
• オフライン入力と後同期が動作する

#10 [技術検証] オフライン/エッジ推論の動作検証とベンチマーク

P1 infra dev research

背景

船内は低帯域・間欠通信のため、クラウドLLM常時接続は非現実的。エッジ推論(GPU不要・16GB RAM想定)+低帯域メタデータ同期のアーキが必要。船内旧式ハードでの動作可否がボトルネックになりうる。

目的

想定船内スペックでエッジ推論が成立するかを定量検証し、モデル選定とアーキ方針を確定する。

タスク

• [ ] 量子化モデルを船内想定スペック(CPU/16GB RAM/GPUなし)で動作検証
• [ ] 推論レイテンシ・コールドスタート・メモリ使用量を計測
• [ ] 日本語/多言語の応答品質をベンチマーク
• [ ] 低帯域メタデータ同期(1日あたり同期量)の方式を試作
• [ ] クラウド版とエッジ版のハイブリッド方針を整理

受け入れ条件

• 船内想定スペックでの推論性能が数値化されている
• モデル選定とアーキ方針が確定している
• 同期方式の試作が動作している

#11 [技術検証] 評価基準とベンチマークデータセットの整備

P1 research dev

背景

安全クリティカル領域では正答率・ハルシネーション率・出典正確性・多言語精度を定量評価しないとMVP移行判断ができない。検証型RAGの効果を客観的に示す必要がある。

目的

PoCとMVPを通じて使う評価基準・ベンチマークデータセット・合格ライン(SLO)を定義する。

タスク

• [ ] 評価指標(正答率/ハルシネーション率/出典正確性/回答拒否の妥当性/多言語精度)を定義
• [ ] 海事ドメインのQ&A評価データセット(規制・機器・労務)を作成
• [ ] 自動評価スクリプトを実装
• [ ] 合格ライン(MVP移行のSLO)を設定
• [ ] PoC各機能のベースライン測定

受け入れ条件

• 評価指標と合格ラインが文書化されている
• 評価データセットと自動評価スクリプトが存在する
• PoC機能のベースライン数値が記録されている

Phase 3: MVP開発

#12 [MVP開発] 船内エッジアプリ+陸上管理コンソールの基盤構築

P0 dev infra

背景

MVPは船内(オフライン耐性のエッジアプリ)と陸上(管理コンソール)を低帯域メタデータ同期でつなぐ構成。PoCで確定したアーキ方針を実装に落とす。

目的

パイロット運用に耐える船内エッジアプリと陸上管理コンソールの基盤を構築する。

タスク

• [ ] 船内エッジアプリの基盤(ローカル推論・ローカルDB・オフライン動作)を実装
• [ ] 陸上管理コンソール(船隊横断の閲覧・設定・ナレッジ更新)を実装
• [ ] 船陸間の低帯域メタデータ同期・自己修復/再送を実装
• [ ] 認証・ロール(船員/陸上監督/管理者)を実装
• [ ] デプロイ/更新(モデル・ナレッジの定期配信)フローを構築

受け入れ条件

• 船内アプリがオフラインで起動・動作する
• 陸上コンソールから船隊の状態を確認できる
• 通信回復時にメタデータ同期が成立する

#13 [MVP開発] 多言語船員向け業務チャットボット+報告自動生成

P0 dev

背景

多国籍船員(英語非母語)の専門用語の壁が安全に影響する。船内オフラインの業務チャットボット(機器マニュアル/SMS/規制Q&A)+ノンレポート/点検記録の自動生成で、理解・手順遵守を支援しPSC指摘・ヒューマンエラーを削減できる。

目的

検証型RAGとノンレポート自動生成を統合し、多言語で使える船員向け業務アシスタントをMVPとして実装する。

タスク

• [ ] 検証型RAGを組み込んだ業務チャットボットを実装(日本語/英語+1言語)
• [ ] 機器マニュアル/SMS/規制ナレッジの船内検索を実装
• [ ] 音声・スマホ入力からの日報/点検記録/インシデント報告自動生成を実装
• [ ] 安全クリティカル手順は要約せず全文提示する設計を実装
• [ ] 陸上(DPA/HSEQ)への報告品質の均一化(LLM一次審査)を実装

受け入れ条件

• 多言語で出典付き回答が返る
• 口頭/手入力から各種報告が自動生成される
• 安全クリティカル手順が全文提示される

#14 [MVP開発] 規制Q&A/PSC受検チェックリスト生成(人間レビュー前提)

P1 dev

背景

PSC受検準備は証書・記録の整合確認が膨大で、不備があればディテンションのリスク。MoU別頻出不具合(ISM/防火/救命/MLC)と自船点検記録を突合し、リスクスコアと是正チェックリストを自動生成できる。最終判断は人間が担保する。

目的

規制Q&AとPSC受検支援(チェックリスト・是正案ドラフト)をMVPに実装し、ディテンションリスクを下げる。

タスク

• [ ] MoU別頻出不具合ナレッジと自船点検記録を突合するロジックを実装
• [ ] PSC受検チェックリスト・想定問答・是正措置案を自動生成
• [ ] 証書/休息時間の期限切れ・違反アラートを実装
• [ ] 出典付き・人間承認ワークフローを組み込む
• [ ] 規制改正の追随(レギュラトリ・ウォッチの下書き提示)を実装

受け入れ条件

• 自船データからPSC受検チェックリストが生成される
• 証書/休息時間の違反が事前アラートされる
• すべての出力が出典付きで人間承認フローを経る

#15 [MVP開発] AIガバナンス基盤(監査ログ・出典トレーサビリティ・PII保護・改ざん検知)

P0 dev infra

背景

EU AI Act・MEPC.312(74)・MASS Codeは自動ログ・人間監督・改ざん検知・データガバナンスを要求。船員PIIをログに残さない・船内データ分離・改ざん検知が安全な運用の前提。これを横断機能として実装する。

目的

MVP全機能を貫くAIガバナンス基盤を実装し、規制提出物に耐える監査証跡と安全性を担保する。

タスク

• [ ] 全AI入出力の監査ログ(誰が/いつ/どの出典で/承認状態)を記録
• [ ] 出典トレーサビリティ(回答→根拠文書ページへの追跡)を実装
• [ ] PII非保持/マスキング・船内データ分離を実装
• [ ] 改ざん検知(ハッシュ・署名)を実装
• [ ] 人間承認ワークフローを全機能に組み込み、confidence表示を統一

受け入れ条件

• 全AI出力に監査ログと出典追跡が残る
• PIIがログ/外部送信に残らないことを検証済み
• 改ざん検知と人間承認フローが動作する

#16 [MVP開発] パイロット導入・効果測定(1社・1〜数隻)

P0 docs dev

背景

提案資料・事業化判断にはパイロット実績が不可欠。報告業務時間削減率・転記ミス削減・PSC指摘削減・利用者満足度を実測する。先行事例(商船三井 配乗計画7割削減/SIMS3/大東汽船 作成送信時間半減)が比較ベンチ。

目的

パイロット船舶管理会社1社・1〜数隻で実運用し、定量効果と現場フィードバックを収集する。

タスク

• [ ] パイロット先の選定と導入計画(対象船・期間・KPI)策定
• [ ] オンボーディング(ナレッジ取り込み・船員教育・船内設置)
• [ ] KPI(報告時間削減率/転記ミス/PSC準備工数/満足度)の事前・事後測定
• [ ] 現場フィードバック収集と不具合トリアージ
• [ ] 効果測定レポート作成

受け入れ条件

• 1社・1隻以上で実運用が行われた
• 報告業務時間削減率など主要KPIが事前事後で測定されている
• 効果測定レポートと改善バックログが整備されている

Phase 4: 提案・展開

#17 [提案] 提案資料・ROIモデルの作成

P0 docs

背景

船舶管理会社/JSA・業界団体・補助金チャネルへ提案するため、課題→ソリューション→パイロット実績→ROI→導入ステップ→価格を1つの説得力ある資料に束ねる必要がある。中小は『何から始めればよいか分からない』(62%)が最大障壁のため、小さく始める伴走型ストーリーが鍵。

目的

パイロット実績に基づく提案資料一式とROIモデルを作成し、商談・チャネル開拓に使える状態にする。

タスク

• [ ] 課題・ソリューション・差別化(日本語/オフライン/検証型RAG/伴走)を1ストーリーに構成
• [ ] パイロット実績(KPI改善)をビジュアル化
• [ ] ROIモデル(報告時間削減・PSC指摘削減・配乗工数削減の金額換算)を作成
• [ ] 導入ステップ(小さな実証→拡大)と価格モデル(サブスク+伴走支援)を提示
• [ ] 補助金活用(省力化投資促進・海事産業強化法支援)の道筋を明記

受け入れ条件

• 提案資料一式が完成しレビュー済み
• ROIモデルが先行事例とパイロット実績を根拠に提示されている
• 価格モデルと補助金活用スキームが含まれている

#18 [提案] 船級承認・コンプライアンス対応ロードマップ作成

P1 docs research

背景

MARITIME 7はClassNK PMS形式承認を取得、Orca AIや川崎重工システムはClassNK技術評価/AiPを取得するなど、船級協会のAI認証が現実に進む。MASS Code・EU AI Act対応も差別化・信頼の源泉になる。中小顧客の導入意思決定を後押しするため認証ロードマップが必要。

目的

製品の信頼性を高める船級承認・規制対応の道筋を整理し、提案・事業計画に組み込む。

タスク

• [ ] ClassNK形式承認/技術評価の対象範囲と取得手順を調査
• [ ] MASS Code・EU AI Act・MEPC.312(74)への対応状況と未対応項目を整理
• [ ] 認証取得のスケジュールと必要工数を見積もり
• [ ] 認証を提案資料の信頼性訴求にどう使うか整理
• [ ] 域外適用(EU寄港・EU向けサービス)リスクの対応方針を記述

受け入れ条件

• 船級承認・規制対応ロードマップが文書化されている
• 取得対象・手順・スケジュールが明記されている
• 提案資料での訴求方法が整理されている

#19 [提案] JSA・業界団体・補助金チャネル開拓と横展開計画

P2 docs research

背景

JSA(会員127社)は自前のDXツールを持たず、政策提言・需要喚起者の位置づけで現場ソフトは空白。JSAや業界団体・補助金チャネルは需要への橋渡しとして有力。中小内航向けには『伴走型導入パッケージ』として横展開する土台が必要。

目的

需要喚起チャネル(JSA/業界団体/補助金)を活用した展開戦略と、横展開のオンボーディング標準を策定する。

タスク

• [ ] JSA・内航総連・SECOJ等業界団体との連携シナリオを整理
• [ ] 補助金(省力化投資促進・海事産業強化法支援等)の申請支援メニューを設計
• [ ] 対象セグメント拡大計画(外航→内航、規模別)を策定
• [ ] オンボーディング標準(ナレッジ取込・教育・伴走)をテンプレ化
• [ ] サポート体制(低帯域前提の運用保守)を設計

受け入れ条件

• チャネル開拓計画と横展開計画が文書化されている
• 補助金活用の申請支援メニューが具体化されている
• オンボーディング標準とサポート体制が定義されている