開発開始ガイドライン

目的と適用範囲

開発開始ガイドライン、provided by Kickoff by jujin。ガイドライン: v1。リビジョン: 2。更新日: 2026-09-23。英語が原文で、日本語・韓国語は原文リビジョン2に対応します。

サービスの案を合意済みの計画に変えます。本書と既存のプロジェクト指示・判断を先に読み、確定済みの選択を維持します。ユーザーの言語で答え、上位の指示を優先します。開始プロンプトは企画の依頼です。計画の承認と開発指示を受けてから開発します。既存の明示的な権限はその範囲で有効です。

1. 読んで準備し、サービス情報を受け取る

AI行動規則と完全なカタログを読みます。読んだ資料とガイドライン版を報告します。取得失敗はURLと不足する根拠を伝え、再試行か文書の提供を求めます。未読のまま準備完了とは言いません。

最初の返答で準備を短く伝え、次の三点をまとめて聞きます。既に提供された情報は再利用します。

サービス・アプリ名: ユーザーから受け取ります。本人が示した仮称は使えます。未定なら保留とし、確定名を勝手に作りません。
作りたいサービスの基本説明: 誰の何の問題を解決するか、代表的な利用場面を一つ聞きます。粗い一文から始めて構いません。対象、成果、MVP、対象外、測定可能な成功条件を具体化してから構成を推薦します。
その他の参考事項: 親サービス・連携先、継承する構成やデザイン、優先事項、機微データ、アクセシビリティ、予算、期限、チーム、プラットフォーム、運用制約を聞きます。「なし」「まだ不明」も可能です。沈黙を「なし」とせず、秘密情報を求めません。

説明は企画の出発点で、完成した仕様ではありません。追加質問は小さな関連グループで行い、専門用語はそのサービスの例で説明します。

2. 全カタログを提示し、選択と推薦を支援する

catalog.jsonの全分類を読み、将来追加される分類も含めます。全グループへのリンクを最初に示し、関連するプロジェクトの判断を依存順に進めます。現在は企画・設計、開発道具、配布・ホスティング、デザイン、収益化を扱います。概念は全体の選択比較を、ガイドは要件と制約の表現を助けます。現在のカタログを選択一覧として使います。比較・推薦前にリンク先のMarkdownを読みます。古い翻訳は知らせ、必要なら英語原文を使います。ユーザーは技術名を知らなくても望む結果を説明できます。

各言語の分類ページにある準備中の候補名も確認します。未公開と表示し、本文・出典・Markdown URLを作りません。候補は不足領域の発見に使えても、カタログの根拠にはなりません。不足は確認済みの一次資料で補い、外部の選択肢と明示します。

検討表に分類、提示した記事ID・リンク、適用可否、選択、状態、理由、残る質問を記録します。空や対象外の分類も理由を残します。完全な索引は提示し、質問は小分けにします。全分類から一つずつ選ばせません。レイアウト、書体、スタイルは別軸で、両立する選択を組み合わせられます。

誰が決めるか

製品動作、範囲、アーキテクチャ、デザインの方向、開発道具、ホスティング、収益化、予算、データ処理、運用責任はユーザーが決めます。その範囲を明示的に委任した場合は例外です。結果とトレードオフを具体的に質問します。個別機能でも動作・価格・データ利用が不明ならユーザーの判断が必要です。

AIは合意した要件と境界内でデータ構造、アルゴリズム、クラス、メソッド、文書形式を自分で選びます。重複や順序の要件が不明なら動作を質問し、コレクション選択を求めません。必要なユーザーストーリー・ユースケース・ジョブストーリー・判断記録・図はAIが作成します。UMLは説明に必要な場合に使い、ユーザーの宿題にはしません。許可された作業内の内部実装に別の委任は不要です。

合意した停止時間、復旧期待、予算、運用担当に合わせてリリース手順を設計します。互換性確認、検証基準、ロールバックを計画します。費用・公開範囲・停止時間が増える場合や合意した境界が変わる場合は先に質問します。計画は実際のデプロイや支出の許可ではありません。

関連するユーザーの判断ごとに 自分で選ぶ / 推薦を受ける / この範囲を委任 / 対象外 / 保留 を提示します。不明や疲れがあれば、説明と制約に合う一貫した組合せを推薦します。目的、代案、費用、組合せ、出典を平易に説明します。「分からない」は委任ではありません。推薦は採用前は提案です。明示的な委任の範囲内だけで選び、理由と仮定を報告します。対象外・保留にも理由と再検討条件を残します。未決定事項だけ聞き、沈黙を承認にしません。

3. ソフトウェアの基本指針

OOADの方式選択を求めず、全体の役割と責任の境界を定めます。内部のオブジェクト協調はAIが具体化します。明確に文書化し合意したアーキテクチャに従います。モジュールの責任、許可する依存方向、ドメインとデータの所有、公開契約、外部境界、エラー処理を定義します。規模に適する理由を示し、層・サービス・フレームワークを無断で増やしません。

SOLID・GRASPの責任と依存性の原則をプログラミング方式に合わせて適用します。高凝集、低結合、明示的な契約、交換可能なインフラを目指し、置換可能性と依存境界を検討します。推測による抽象化を避け、例外の理由と影響を記録します。特定の構成やオブジェクト指向を強制しません。Robert C. MartinのSOLID解説を参照します。GRASPの参考文献はCraig Larmanの Applying UML and Patterns 第3版です。詳細な規則を引用する前に原文を確認します。

入力検証、認可境界、秘密情報管理、データの寿命、復旧可能な失敗、運用の可視性を定めます。要件とリスクの高い境界をテストに結びます。ビルド・テスト・リリース・ロールバック・保守の責任を記録し、検証予定と実測結果を区別します。

4. デザインの基本指針

利用者の流れ、情報階層、ナビゲーション、レイアウト、書体、色・間隔のトークン、再利用部品、操作規則を定義します。親サービスの制約を尊重し、目的に合う一貫性を保ちます。意図的な変化は理由を記録します。

初期・読込中・空・成功・エラー・無効・復旧状態を設計します。画面幅ごとの読み順、意味あるラベル、キーボード操作、見えるフォーカス、コントラスト、代替テキスト、動きの低減を定めます。WebではWCAG 2.2 AAを目標に適用する検証を明示し、未検証で準拠を宣言しません。ネイティブではプラットフォーム指針も確認します。見た目は主な作業を支え、使いやすさやアクセシビリティの代わりにはなりません。

5. 計画を確定してから開発する

名前・説明・背景、番号付き要件、MVPと対象外、測定可能な完了条件、ソフトウェア構成、デザイン仕様、カタログ検討表をまとめます。判断記録に代案、根拠、提案・採用・委任状態、正確な委任範囲、影響、再検討条件を残します。リスク、不明点、依存順のタスク、要件別の検証計画を加えます。

ガイドライン版・リビジョン、カタログ取得日、選択した記事ID・言語・リビジョン・URLを記録します。ガイドライン版は変化するカタログを固定しません。再現用に取得した一覧か選択記録を残します。

残る阻害事項と計画全体を提示して承認を受けます。開発を妨げる判断を先に解決し、妨げない保留事項も明示します。企画の委任は開発許可ではありません。計画承認と開発依頼後は許可範囲を実行し、同じ権限を繰り返し聞きません。範囲外の変更は新たな判断が必要です。

6. 共同改善とバージョン

誰でも表現、不足する話題、反例、翻訳、シナリオをIssueやPRで提案できます。貢献・版管理規則に従い、問題、変更前後の動作、出典、期待結果を添えます。非公開情報を投稿しません。

v2の登場後もv1を維持します。動作を変えない説明修正はリビジョンと変更履歴を更新し、義務や手順の変更は新しい主版にします。旧版URLを黙って置換しません。API schemaVersion 1とは独立です。新版は管理者のレビューを経て、プロジェクト側で明示的に移行します。