開発計画・技術選定学習記事全11節Design
作り方を決める前に、社内の制約を確認済み・未確認・仮定に分ける
この記事で身につくこと端末・ネットワーク・データ持出し・利用可能なAI・予算・運用担当という制約を、確認済み・未確認・仮定に分けて整理し、未確認のまま進める危険を説明できる。
記事内目次（24項目）
この記事の会社・人物・社内ルールはすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。作り方（方式や技術）を決める前に、その会社で「使ってよい端末」「使ってよいAIサービス」「外部に出してよいデータ」といった制約を確認する話です。
なぜ必要か。制約を確認せずに作り方を決めると、後になって「そのAIサービスは社内ルールで使えない」「そのデータを外部に送ってはいけない」と分かり、作り直しになることがあります。
この記事を読むとできるようになること。
- 端末・ネットワーク・データ持出し・利用可能なAI・予算・運用担当の6分類で制約を整理できる
- 各制約が「確認済み」「未確認」「仮定」のどれかを区別できる
- 未確認の制約を仮定のまま進める場合の危険と、確認先を書ける
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節→第4節→第5.2節の表→第9節。ここまでで「6分類」と「確認状況の区別」が分かり、ひな形を埋め始められます。
- 作って確かめる：上に加えて第5.3節（AIへの依頼）→第6節（失敗例と直し方）→第7節。
- 設計判断を深める：上に加えて第8節（選択肢を強く限定する制約、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、記事A（02-01）の業務要件を実現する「作り方」を選ぶ前に、その選び方を制限する社内の制約（端末、ネットワーク、データの扱い、使ってよいAI、予算、誰が運用するか）を確認し、一覧にすることです。
要件（何をできるようにするか）が決まっても、それをどう作るかは会社ごとの事情で変わります。私物端末が使えるか、依頼の内容を外部のAIサービスに送ってよいか、といった制約を確認しないまま作り方を決めると、後から作り直すことになります。
この記事を読み終えると、次のものが手元にできます。
- 端末・ネットワーク・データ持出し・利用可能なAI・予算・運用担当の制約一覧
- 各制約の確認状況（確認済み・未確認・仮定）
- AIへ渡してよい情報の範囲
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
制約
一言でいうと、作り方の選択肢を狭める、会社ごとの決まりや事情です。
たとえば、「私物端末の業務利用を禁止する」という社内ルールがあれば、「個人のスマートフォンで使えるアプリ」という選択肢は最初から外れます。
これがないと、実現できない作り方を検討する時間が無駄になったり、逆に禁止されている方法を知らずに進めてしまったりします。
確認状況（確認済み・未確認・仮定）
一言でいうと、その制約について、本当に確かめたのか、まだ確かめていないのか、確かめる前に仮に置いているのかの区別です。この記事では「仮定」を、まだ確かめていないが安全側に倒して仮に置く場合と、正本（既存記事）に根拠がなく、演習のためにこの記事が新しく設定した「教材上の仮定」の、2つの意味で使います。
たとえば、依頼者・承認者・運用管理者という役割そのものは記事Aで確認済みです。一方、「会社支給のノートPCのみ許可する」といった具体的な社内ルールは、記事Aにも他の正本にも根拠がなく、この記事が演習のために置いた教材上の仮定です。「依頼の内容を外部のAIサービスに送ってよいか」はまだ確認していません（未確認）。
これがないと、「確認したこと」と「教材として仮に置いたこと」と「まだ確認していないこと」が混ざり、教材上の仮定を確認済みの事実のように扱ってしまう危険があります。
読む順路：制約のもとになる業務要件は記事A（02-01）が該当します。制約を踏まえた作り方の比較は03-02、AIへ渡してよい範囲の具体化は07-01が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。
3. 理解する：なぜ作り方より先に制約を確認するのか
3.1 「まず作ってみる」の危険
制約を確認せずに作り方を決めると、次のことが起きます。
- 私物端末や個人契約のAIサービスを前提に検討を進めたあと、社内ルールで使えないと分かり、検討し直しになる
- 依頼の内容を外部のAIサービスに送る前提で進めたあと、社外秘の情報を含む可能性があると分かり、作り方を見直すことになる
- 誰が運用するかを決めずに進め、完成してから運用担当が決まらず使われない
制約は「作り方を狭めるもの」であると同時に、「後から気づいて作り直す」ことを防ぐための情報です。
3.2 よくある誤解
「制約は情報システム部門が決めることで、この記事とは関係ない」。誰が最終的に決めるとしても、作り方を検討する人が制約を知らなければ、実現できない案を検討することになります。
「確認できていない制約は、後で確認すればよい」。未確認のまま作り方を決めると、後から確認した結果によっては作り直しになります。この記事では、未確認のまま進める場合の危険を明記します。
「予算はいつも『できるだけ安く』でよい」。予算の枠が決まっていない状態で作り方を比較すると、比較の軸がぶれます。予算が未確認なら、未確認であることを明記して進めます。
「AIに社内ルールを聞けば分かる」。AIは一般的な確認項目の候補を示せますが、この会社で実際に何が許可されているかは、社内の責任者に確認する必要があります（第4.3節）。
4. 判断すること
4.1 何を確認すればよいか
| 分類 | 確認すること | この記事での扱い |
|---|---|---|
| 端末 | 業務利用が許可されている端末の種類 | 会社支給のノートPCのみ許可されている、という教材上の仮定で進める（正本に根拠なし） |
| ネットワーク | どこからのアクセスを許可するか | 社内ネットワークのみ利用できる、という教材上の仮定で進める（正本に根拠なし）。社外（自宅等）からのアクセス可否は未確認 |
| データ持出し | 依頼の内容を外部サービスへ送ってよいか | 未確認。社外秘の情報を含む可能性があるため、確認するまでは「送らない」を仮定とする |
| 利用可能なAI | 社内で契約済みのAIサービス以外を使えるか | 社内契約済みのAIサービスのみ利用可、という教材上の仮定で進める（正本に根拠なし） |
| 予算 | 開発・運用にかけられる予算の枠 | 未確認。金額を伴う比較（03-03、03-04）は「予算未確定」を前提に進める |
| 運用担当 | 誰が運用するか | 運用管理者という役割は記事Aで確認済み。「総務の担当者1名」という人数は正本に根拠がなく、教材上の仮定とする |
4.2 勝手に決めてはいけないこと
- 各制約が「確認済み」か「未確認」かは、実際に確認した事実に基づいて書きます。都合よく「確認済み」にしません。
- 正本（記事Aなど既存記事）に根拠がない具体的なルール（端末の種類、利用できるAIサービスの範囲、運用担当の人数など）は「確認済み」として扱いません。演習のために置いた「教材上の仮定」として明記します。
- データ持出しのように、社外秘の情報が関わる可能性がある制約は、未確認の間は「禁止（仮定）」の側に倒します。安全でない側を仮定にしません。
- 記事Aで決めた役割・業務要件を、この記事で変更しません。
4.3 AIに任せる範囲
一般的に確認される制約の項目（端末、ネットワーク、データ、AI、予算、運用担当という分類そのもの）の提示はAIに任せられます。しかし、この会社で実際にどこまで許可されているかの判断は、社内の責任者が行います。
5. 作って確かめる：制約一覧を作る
5.1 準備
記事Aの成果物（業務要件一覧の記入例）を用意します。
5.2 制約・前提条件一覧
| 分類 | 内容 | 出所 | 確認状況 | 影響する判断 |
|---|---|---|---|---|
| 端末 | 会社支給のノートPCのみ業務利用を許可する（教材上の仮定） | 教材上の設定（正本に記載なし） | 仮定 | 03-02の方式比較で、私物端末前提の案は候補から外れる（この仮定が前提） |
| ネットワーク | 社内ネットワークからのアクセスのみ許可する（教材上の仮定）。社外からのアクセス可否は未確認 | 教材上の設定（正本に記載なし）／未確認 | 仮定（社内限定）・未確認（社外可否） | 社外からの利用が必要になった場合、追加のネットワーク確認が必要。それまでは仮定に基づく比較例として扱う |
| データ持出し | 依頼の件名・内容を外部のAIサービスへ送ってよいかが未確認 | 未確認（記事A Q-6と同じ論点） | 未確認（仮定：確認できるまで送らない） | 07-01でAIへ渡してよい情報の範囲を「社外秘を含まない架空データのみ」に限定する |
| 利用可能なAI | 社内で契約済みのAIサービスのみ利用してよい（教材上の仮定） | 教材上の設定（正本に記載なし） | 仮定 | 03-03の技術選定で、個人契約のAIサービスは候補から外れる（この仮定が前提） |
| 予算 | 開発・運用にかけられる予算の枠がまだ決まっていない | 未確認 | 未確認（仮定：予算未確定として進める） | 03-04の計画で、費用は見積条件付きとし、確定値と区別する |
| 運用担当 | 運用管理者という役割は記事Aに存在する。「総務の担当者1名」という人数は正本に根拠がなく、教材上の仮定とする | 記事A（02-01、役割）／教材上の設定（人数） | 一部確認済み（役割）・仮定（人数） | 03-04の役割表に引き継ぐが、人数は仮定であることに留意する |
5.3 AIに制約一覧の下書きを頼む
一般的に確認すべき制約の項目の候補をAIに出させます。
みらい業務サービスの依頼・承認管理アプリを作るにあたり、事前に確認すべき社内の制約を、端末・ネットワーク・データ持出し・利用可能なAI・予算・運用担当の6分類で整理したいです。
依頼：
1. 各分類で、一般的に確認しておくべき項目の候補を挙げてください。
2. 確認できていない項目は「未確認」として扱ってください。実際の社内ルールを断定しないでください。
してはいけないこと：
- この会社の実際のルールを知っているかのように断定しないでください。
- 記事Aにない新しい要件を前提にした制約を作らないでください。6. 初稿・失敗例・修正
6.1 説明用の失敗例（AIの初稿という設定）
AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。
- 「クラウドサービスの利用は自由」と、確認していない事実を断定的に記載
- 「予算は月額5万円程度」と、実測していない金額を仮定ではなく確定値として記載
6.2 見つけ方と直し方
- 「クラウドサービスの利用は自由」：確認していないことを断定しています。「未確認」に修正します。
- 「予算は月額5万円程度」：実際に決まった金額ではありません。設計書6.3の「実測していない数値を書かない」に反します。「未確認」に修正します。
指摘：
1. 「クラウドサービスの利用は自由」は確認していません。「未確認」に修正してください。
2. 予算の金額は決まっていません。金額を書かず「未確認」としてください。
変えないこと：
- 端末・利用可能なAIの教材上の仮定、運用担当の確認済み（役割）部分は変更しないでください。6.3 修正後の制約一覧
修正後の制約一覧は、第5.2節の表のとおりです。
7. 確認結果
第5.2節の制約一覧を、完了条件と照合します。
| 完了条件 | 確認結果 |
|---|---|
| 端末・ネットワーク・データ・AI・予算・運用担当の6分類がある | 6分類すべてに1件以上あり |
| 各行に確認状況（確認済み／未確認／仮定）がある | 6件すべてに確認状況を明記 |
| AIへ渡してよい情報の範囲が明記されている | データ持出しの行に「社外秘を含まない架空データのみ」と明記 |
残る制限：この制約一覧は架空の設定です。端末・ネットワーク（社内限定の部分）・利用可能なAI・運用担当の人数（総務の担当者1名）は、正本に根拠のない教材上の仮定であり、実際の企業では改めて確認が必要な想定です。ネットワーク（社外可否）・データ持出し・予算については実際に確認しておらず、確認できるまでは安全な側（禁止・未確定）を仮定として扱っています。この記事の本文と記入例はClaude Codeが作成したもので、社内の責任者による確認は行っていません。
8. 設計を判断する
8.1 選択肢を強く限定する制約はどれか
| 制約 | 選択肢を限定する強さ | 理由 |
|---|---|---|
| 利用可能なAI（社内契約済みのみ、教材上の仮定） | 強い | 03-03の技術選定で使えるAIサービスの候補が大きく絞られる（この仮定を前提にした場合） |
| 端末（会社支給のみ、教材上の仮定） | 中 | 私物端末を前提にした案が外れるが、Webアプリなど端末を選ばない方式は影響が少ない（この仮定を前提にした場合） |
| データ持出し（未確認） | 強い（未確認のため潜在的に強い） | 確認の結果次第で、外部サービスを使う案が丸ごと使えなくなる可能性がある |
| 予算（未確認） | 中〜強（未確認のため方式によって変わる） | 高機能な方式ほど費用がかかりやすく、予算次第で候補から外れることがある |
データ持出しと予算は、未確認であること自体が「選択肢を強く限定する可能性がある制約」です。利用可能なAI・端末は教材上の仮定であり、実際の企業では確認の結果次第で判断が変わります。03-02で作り方を比較する前に、未確認の項目は確認を進め、教材上の仮定の項目は仮定であることを踏まえて比較することが望ましいと考えられます。
8.2 適用限界
この記事の制約一覧は、架空企業「みらい業務サービス」を前提にした一例です。端末・ネットワーク（社内限定）・利用可能なAI・運用担当の人数は、この記事が演習のために置いた教材上の仮定であり、実在する企業のルールではありません。実際の会社では、法令・業界規則・情報セキュリティ方針など、この記事にない分類の制約が必要になることもあります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 制約・前提条件一覧ひな形（分類、内容、出所、確認状況、影響する判断） | templates/03-01-constraints_template.md | templates/03-01-constraints_example.md |
自分の業務に使うときの手順は次のとおりです。
- 前工程（記事A、02-01）の業務要件一覧を用意する
- 端末・ネットワーク・データ持出し・利用可能なAI・予算・運用担当の6分類で確認すべきことを挙げる
- 各項目を確認し、確認済み・未確認・仮定のいずれかに分類する
- 未確認の項目は、確認できるまで安全な側を仮定として明記する
- AIへ渡してよい情報の範囲を明記する
10. 次工程への受渡し
次へ渡すもの：制約・前提条件一覧（分類・内容・確認状況・影響する判断）。
次工程での使われ方：03-02（作り方の候補を比較する）では、この制約一覧が比較条件になります。07-01（AIに渡す資料を整える）では、データ持出しの制約がAIへ渡してよい情報の範囲の根拠になります。
前工程へ戻る条件：データ持出しや予算の確認結果によって業務要件そのものを見直す必要が出たら、記事A（02-01）に戻ります。
11. 根拠と更新情報
- この記事の会社・人物・社内ルールはすべて架空の設定です。
- 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
- 6分類（端末・ネットワーク・データ持出し・利用可能なAI・予算・運用担当）は、教材設計書
AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第3節のCONTENT_MAP該当箇所に基づきます。CONTENT_MAPが指定するのはこの6分類のみであり、各分類の具体的な内容（会社支給PCのみ、社内契約AIのみ等）は正本にはなく、この記事が演習のために置いた教材上の仮定です。 - 運用管理者という役割は記事Aの記入例で確認済みです。「総務の担当者1名」という人数は記事Aにも他の正本にも記載がなく、この記事が置いた教材上の仮定です。
- 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
- 未確認事項：ネットワーク（社外可否）・データ持出し・予算は実際に確認しておらず、安全な側を仮定として進めています。端末・ネットワーク（社内限定）・利用可能なAI・運用担当の人数は、確認の有無以前に、正本に根拠のない教材上の仮定であることに留意してください。
- 更新履歴：2026-09-20、ユーザーレビューにより、端末・ネットワーク（社内限定）・利用可能なAI・運用担当の人数を「確認済み」から「教材上の仮定」に訂正しました（正本に根拠がないため）。