経緯

私は大手日系 SIer で 7 年 SE をやってきました。今はフリーランスのインフラエンジニアとして、AWS の構築案件を中心にやっています。

オンプレ時代から SI 業界の「設計書地獄」を見てきましたが、クラウド時代になっても Excel パラメータシートの手書き地獄は消えていません。

こんなこと、まだやってませんか？

AWS マネジメントコンソールを開いて、設定値を Excel に1つずつ転記
リソースが 20 個あれば、丸 1 日 Excel と向き合う
命名規則の不統一でレビュー差し戻し → 全リソース見直し
Terraform 化してるのに、顧客提出用の Excel パラメータシートは別途作成
ChatGPT に頼ろうにも、VPC や Security Group の文脈をいまいち理解してくれない

私もずっとやってきました。SE の本業はシステムを作ることで、Excel を埋めることじゃない。

なぜ作るか — 市場の隙間を狙う

設計書 AI といえば 2026 年 2 月から本格提供開始した富士通 Takane が話題ですが、これは大企業向け（数百万〜）。フリーランスや中小 SIer は射程外です。

Jitera は コード→設計書（リバース） が主軸。
Pulumi AI は 自然言語→IaCコード。

つまり、「設計書 → 設計書（順方向の連鎖）」を扱うサービスは、特にインフラ系で空白地帯 なんです。

富士通 Takane:        要件 → 全工程 → コード（大企業向け、高額）
Jitera:               コード → 設計書（リバース）
Pulumi AI:            自然言語 → IaCコード（人が読む設計書ではない）
DocChain（これから）: 設計書 → 設計書（順方向、フリーランス・中小向け）

DocChain の構想

フリーランスSE / 中小SIer 向けの、設計書連鎖生成 AI です。

連鎖の流れ

【開発系】
要件定義書 → 基本設計書 → 詳細設計書 → テスト仕様書
                                          ↑ MVP 主戦場

【インフラ系】
要件定義書 → 基本設計書 → パラメータシート → 構築テスト
                            ↑ MVP 主戦場

なぜ「開発系」と「インフラ系」を分けるのか

最初は 1 つのスキーマで両方カバーしようと思いました。

しかし、詳細設計書の本質が違うことに気付きました:

開発系の詳細設計書: 処理ロジックの記述
インフラ系の詳細設計書: パラメータシート（VM 名・IP・サイズの一覧表）

同じ「詳細設計書」という名前でも、出力フォーマットを共通化するのは無理。なので 完全に 2 系統で分離 しました。

スキーマ設計の工夫

連鎖生成のキーは 「上流の設計書のどのフィールドを参照すべきか」を機械的に明示 することです。

meta:
  document_id: PARAM-INFRA-001
  document_type: detailed_design
  system: infra
  provider: aws
  references:
    - ref_id: BASIC-INFRA-001
      ref_type: basic_design
      purpose: parent
    - ref_id: BASIC-INFRA-001
      ref_type: basic_design
      purpose: data_source
      source_field: content.naming_convention

purpose: data_source で「LLM が次の設計書を生成するとき、どのフィールドを引用すべきか」を構造化しました。

ChatGPT に「スキーマ構造として妥当か？」と相談したところ、parent_refs と dependencies を別フィールドにしていた初期案を references[].purpose に統合すべき という指摘をもらい採用。1ラウンドで設計の質が大きく上がりました。

AWS 専業から始める理由

MVP では AWS のみ対応 にします。理由:

日本市場での AWS シェアが大きい（おそらく 60%超）
私自身が AWS が一番得意（インフラエンジニアとして 7 年の経験）
Azure / GCP / オンプレを最初から抽象化すると、LLM の精度が下がる

ただし、スキーマには provider フィールドを最初から持たせて、v1.5 で Azure、v2 で GCP を追加できる設計にしています。

集客が苦手な個人開発者の現実

正直に言います。私は集客が苦手です。

なので、対面営業や Connpass 登壇、YouTube は最初から捨てます。やるのはこれだけ:

Tier	チャネル
1	既存のブログ (lab.iigtn.com/blog/) を入口にする
2	Builder in Public（週1で Twitter 進捗投稿）
3	事前登録 LP (getdocchain.com)
4	Qiita 月1〜2本（この記事もその一環）

「集客行動」と思うと辛いので、「作業の記録」として書く スタイルで継続します。

事前登録、開始しています

getdocchain.com で事前登録を受け付け中です。

特典（先着 100 名限定）:

ベータ期間中は完全無料
正式リリース後 1 ヶ月無料
機能要望は次のアップデートで優先実装

ベータ公開予定: 2026 年 9 月

次回予告

開発記録は週次で更新します:

詳細設計書 → テスト仕様書のプロンプト試作（GPT-4o）の精度評価
AWS 基本設計書 → パラメータシート自動生成の動作デモ
LP の CVR 計測結果（Plausible Analytics）

「方眼紙 Excel から解放されたい」あなた、ぜひ事前登録お願いします。

🌐 DocChain 公式: https://getdocchain.com/
📝 AWS 構築日誌（運営者の他ブログ）: https://lab.iigtn.com/blog/
🐦 進捗 Twitter: @iigtn_official