経緯
私は大手日系 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