「AIで何かやれ」と経営層から指示されたものの、いざ進めようとすると最初の一歩でつまずく。AI開発を「どの順番で、どこまで、どのフェーズで外注すればいいのか」という全体像が描けず、複数のベンダーから話を聞いても提案の粒度がバラバラで比較できない。そんな状況に置かれている方は少なくありません。
AI開発が難しいのは、通常の業務システム開発と違い「やってみないと精度が読めない」性質を持っているからです。要件を最初に固め切れず、進めながら見えてくる部分が多いため、最初から本番まで一括で発注しようとすると、見積りの根拠が曖昧になり、後から「思っていたものと違う」という事態になりがちです。だからこそ、AI開発はフェーズで区切って段階的に発注する「ロードマップ」の考え方が欠かせません。
特に発注者が抱える最大の不安は、「PoC（概念実証）だけ頼んだ後、本番でハシゴを外されないか」「最初から本番まで一括発注すべきか、段階的に切るべきか」という発注単位の切り方です。この判断軸がないと、ベンダーの提案する範囲が自社にとって過不足ないのかを評価できず、いつまでも稟議の前段で足踏みすることになります。
本記事では、AI開発をPoC・MVP・本番リリース・継続改善の4フェーズに整理し、「各フェーズで何を発注し、何を社内に残すか」という発注設計の地図を提供します。フェーズごとの発注範囲・費用や期間の目安・段階発注で発注者が握るべき判断軸を、そのまま稟議資料に転記できる早見表付きで解説します。読み終えたとき、ベンダー提案を「フェーズのどこをカバーしているか」で評価できるようになり、自社の段階発注計画を自分の言葉で描けるようになることを目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
AI開発ロードマップとは？段階的に発注するための全体地図
AI開発ロードマップとは、AIプロダクトを「PoC → MVP → 本番リリース → 継続改善」という段階に区切り、それぞれのフェーズで何を発注し、何を社内に残すかを定めた発注の設計図です。多くの解説記事はフェーズの「説明書」にとどまりますが、発注者が本当に欲しいのは「発注単位をどこで切るか」という設計図のほうです。本記事はその設計図として読んでください。
なぜAI開発は一括発注に向かないのか
業務システムの開発であれば、要件をある程度固めてから一括で発注し、ウォーターフォール的に進めることもできます。しかしAI開発では、この前提が崩れます。
理由は2つあります。1つ目は精度の不確実性です。AIの性能は、手元のデータの質や量、業務との相性に大きく左右され、実際に学習・検証してみるまで「使い物になる精度が出るか」が読めません。2つ目は要件の後出しです。AIに何を任せられるかは、検証の過程で初めて具体化することが多く、最初に要件を固め切ろうとしても机上の空論になりがちです。
この2つの性質を無視して最初から本番まで一括発注すると、「精度が出ないのに本番開発を進めてしまう」「要件が動くたびに追加費用が膨らむ」といったリスクを発注者が一身に背負うことになります。フェーズで区切る最大の目的は、各段階の終わりで「続行・中止・再設計」を発注者が選べる状態を作り、リスクを小さく刻むことにあります。AIの開発がどのような流れで進むのかをより詳しく知りたい場合は、AI開発の流れ・プロセスもあわせてご覧ください。
ロードマップの4フェーズ（PoC→MVP→本番リリース→継続改善）の全体像
本記事では、AI開発を次の4つのフェーズに整理します。
- PoC（概念実証）フェーズ: 「そもそも実現可能か」を最小投資で確かめる段階。ゴールは成功そのものではなく、「続行・中止・再設計」の意思決定材料を得ることです。
- MVPフェーズ: 検証で見えた価値を、実際に使える最小限のプロダクトとして形にする段階。製品の最初のバージョンを、コア機能に絞って作ります。
- 本番リリースフェーズ: 一部のユーザーだけでなく、業務として継続的に使える品質・体制を整える段階。非機能要件やセキュリティ、運用体制をここで作り込みます。
- 継続改善フェーズ: リリース後も精度の劣化やデータの変化に追従し、改善を続ける段階。AIに「完成」はないため、ここをどう設計するかが長期コストを左右します。
競合解説の多くは「企画・構想 / PoC / 開発・実装 / 運用 / 改善」という5区分を使いますが、本記事は発注の切り口を重ねやすいよう、上記の4区分で整理しています。要件定義は独立フェーズとして切り出さず、PoCとMVPの各段階で「何を作るか」を固める作業として組み込んでいます。AIプロジェクトの要件定義そのものについては、AIプロジェクトの要件定義ガイドで詳しく扱っています。
ここから先は、各フェーズで「何を発注し、何を社内に残すか」を順に見ていきます。
PoCフェーズ｜「実現可能か」を最小投資で確かめる発注
PoCフェーズの目的を、多くの発注者が誤解しています。PoCのゴールは「成功すること」ではありません。「このAIを本番まで進めるべきか、中止すべきか、設計をやり直すべきか」を判断するための材料を、できるだけ小さな投資で手に入れることがゴールです。ここを取り違えると、PoCが「とりあえず動くデモ」を作って終わる、いわゆる技術デモ止まりになってしまいます。
PoCで発注する範囲・しない範囲
PoCで発注すべきなのは、検証スコープを1つの業務・1つのユースケースに絞った、最小限の検証です。具体的には、検証対象データを使った精度の測定、技術的な実現可能性の確認、そして「どの程度の精度なら業務で使えるか」という成功条件の合意までを範囲に含めます。
逆に、PoCで発注しないものを明確にしておくことも重要です。本番を想定したきれいなUI、大量アクセスに耐えるインフラ、複数業務への横展開などは、この段階では発注しません。これらを盛り込むと費用と期間が膨らみ、「実現可能かを確かめる」という本来の目的がぼやけてしまいます。
PoC完了時に受け取るべき成果物チェックリスト
「PoCだけ頼んで終わるのが怖い」という不安への最も具体的な対策は、PoCの契約時点で受け取る成果物をはっきり決めておくことです。PoC完了時には、最低限ここに挙げるものを受け取れるよう発注しましょう。
- 検証結果の評価レポート: 設定した成功条件に対して、実際にどの程度の精度・成果が出たか。続行・中止・再設計のどれを推奨するか、その根拠。
- 検証に使ったコードとデータの取り扱い: 検証コードの受領可否、利用したデータの権利関係。
- 本番フェーズの概算見積り: PoCで見えた前提に基づく、MVP・本番までの費用と期間のラフな見積り。
- 次フェーズに進む場合の推奨アーキテクチャ案: 本番を見据えた技術構成の方向性。
特に重要なのが「本番フェーズの概算見積り」を成果物に含めることです。これをPoC契約の段階で要求しておくと、PoCが終わった後に「次フェーズの主導権」を発注者が握れます。PoCの進め方そのものをさらに具体的に知りたい場合は、AI PoCの進め方をご覧ください。
費用・期間の目安
AI開発のPoCにかかる費用と期間は、検証範囲や対象データの規模によって幅がありますが、おおむねの目安としては費用100万〜300万円程度、期間1〜3ヶ月程度が一つの基準になります。中小規模で対象を1業務に絞れば100万円前後から始めるケースもあり、より大規模・複雑な検証では数百万円規模になることもあります（出典: 株式会社renue「PoC開発とは？AI・DXプロジェクトの概念検証を成功させる進め方・費用【2026年版】」）。
期間については、長引かせるほど成功率が下がる傾向が指摘されています。一般に3ヶ月以内のPoCは成功率が比較的高い一方、6ヶ月以上に伸びると成果が出にくくなるとされ、4〜8週間程度に区切って結果を出す進め方が推奨されています（出典: 株式会社renue「生成AI PoC失敗パターン12選＋本番移行7原則2026」）。発注時には、だらだらと延長しないよう「いつまでに、何をもって判断するか」を期限とセットで握っておきましょう。
MVPフェーズ｜使える最小プロダクトとして発注する
PoCで「続行」の判断が出たら、次はMVPフェーズです。MVPは「Minimum Viable Product（実用最小限の製品）」の略で、検証で見えた価値を、実際に一部のユーザーが使える最小限のプロダクトとして形にする段階です。PoCと本番の間にある"谷"を、このMVPで段階的に埋めていきます。
PoCとMVPの違い（発注観点での区別）
PoCとMVPは混同されがちですが、発注の観点では明確に異なります。
PoCは「検証用」であり、製品化を前提としません。動けばよく、使い捨てられることも珍しくありません。一方MVPは「製品の最初のバージョン」です。実際の業務に組み込み、限られた範囲のユーザーが日常的に使うことを前提とします。
この違いは発注内容に直結します。PoCでは無視してよかった「使い勝手」「最低限の安定性」「データの入出力の流れ」が、MVPでは発注範囲に入ってきます。逆に言えば、PoCで作ったコードをそのまま本番品質として流用しようとすると、ここで品質のギャップに直面します。MVPは「PoCの延長」ではなく「製品としての作り直しの第一歩」と捉えると、発注範囲を見誤りません。
MVPで発注する機能の絞り込み方
MVPで最も重要な発注判断は、「どの機能を入れ、どの機能を捨てるか」です。ここで欲張ってしまうと、MVPがいつまでも完成せず、本番フェーズとの境目が曖昧になります。
機能を絞り込むコツは、検証で「価値があると確認できた中核の体験」だけに集中することです。あれば便利な周辺機能、例外的なケースへの対応、複数部門への横展開などは、いったん後回しにします。発注時には「このMVPで検証したい仮説は何か」を1つに定め、その仮説の検証に必要な機能だけを発注範囲に含めると、スコープがぶれにくくなります。
MVPフェーズで決めておく運用・体制の初期設計
ここで、PoC止まりを防ぐうえで決定的に重要な原則を押さえておきます。それは「業務課題・成功条件・運用設計を、技術選定より先に固める」ということです。
どんなに優れたモデルや技術を選んでも、「誰がこのAIの運用を担うのか」「精度が落ちたとき誰が気づき、誰が直すのか」「現場のどの業務にどう組み込むのか」が決まっていなければ、本番に移った瞬間に機能しなくなります。実際、PoCが本番化しない原因の多くは技術の問題ではなく、運用・体制・評価基準が噛み合っていないことにあるとされています（出典: ビジネス＋IT「生成AIプロジェクトが『PoC死』で終わる3つの原因とその対策」）。
そこでMVPフェーズでは、製品の機能開発と並行して、運用体制の初期設計を発注範囲に含めておきます。運用の担当者、改善のサイクル、成功を測る指標——これらの"初期版"をMVPの段階で描いておくことで、本番フェーズで体制をゼロから作る事態を避けられます。
本番リリースフェーズ｜「死の谷」を越える発注設計
AI開発で最も多くのプロジェクトがつまずくのが、PoCやMVPから本番リリースへ移る局面です。ここは俗に「死の谷」と呼ばれます。BCGの調査では、74%の企業がPoC段階を超えて実際のビジネス価値を創出できていないと報告されています（出典: Boston Consulting Group, AI Adoption in 2024）。発注者が抱く「ハシゴを外されないか」という不安は、決して杞憂ではありません。
なぜPoC止まりになるのか（人材・体制・依存構造）
PoC止まりの正体は、技術的な失敗というより、構造的な問題であることがほとんどです。
第一に、本番運用を担う人材・体制が社内にいないことです。PoCは外部ベンダーが主導して進められますが、本番は日々の運用・監視・改善が必要です。これを誰が担うかが決まっていないと、リリースした瞬間に立ち行かなくなります。
第二に、改善のたびに外部依存が深まる構造です。AIは作って終わりではなく、継続的な改善が前提です。ところが社内に知見が残っていないと、小さな改修のたびにベンダーへ依頼することになり、コストと時間がかさみます。この依存構造こそが、発注者の感じる「ハシゴを外される」感覚の正体です。
第三に、セキュリティやガバナンスの後付けです。「PoCだから簡易で」と判断した結果、本番に必要なアクセス制御・ログ保存・個人情報対策がすべて後追いになり、本番化の直前で大きな手戻りが発生します。
本番フェーズで発注する非機能・運用要件
本番フェーズで発注すべき範囲は、PoC・MVPとは質的に異なります。ここで初めて、機能そのものよりも「業務として安心して使い続けられるか」を支える非機能要件が中心になります。
- 非機能要件: 想定アクセス数に耐える性能、障害時の復旧、データのバックアップ。
- セキュリティ: アクセス権限の管理、個人情報・機密データの取り扱い、生成AIを使う場合は不適切な入出力への対策。
- 監視・監査ログ: AIの判断や入出力を記録し、後から検証・説明できる仕組み。
- 本番移行計画: 既存業務からの切り替え手順、移行期間中の並行運用、問題発生時の切り戻し。
これらは地味ですが、本番運用の信頼性を左右する要です。本番移行をどう設計すればよいかをさらに掘り下げたい場合は、PoCから本番移行する方法を参考にしてください。
本番移行をスムーズにする前フェーズからの引き継ぎ設計
死の谷を越える最大のコツは、本番フェーズで急に準備を始めるのではなく、前のフェーズから本番を見据えて引き継ぎを設計しておくことです。
具体的には、PoCの段階で「本番フェーズの概算見積り」を成果物に含めておく、MVPの段階で「運用体制の初期版」を描いておく、といった先回りが効きます。さらに、各フェーズで作られたコードや設計ドキュメントを発注者側が確実に受け取り、社内に蓄積しておくことも欠かせません。フェーズが変わるたびに情報が断絶すると、その都度ベンダーへの説明や作り直しが発生し、それ自体が死の谷を深くします。本番を「別プロジェクト」ではなく「前フェーズの延長線」として連続させる発注設計が、谷を越える鍵になります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
継続改善フェーズ｜内製と外注のバランスを段階的に切り替える
本番リリースはゴールではなく、AI開発のスタート地点に近いものです。ここからの継続改善フェーズで、「どこまで外注し続けるか」という発注者の最後の問いに向き合うことになります。
AI開発に「完成」がない理由（精度劣化・再学習）
AIは、いったん本番で動き始めても、放っておくと徐々に精度が落ちていきます。これは、AIが学習した時点のデータと、実際の業務で扱うデータが時間とともにズレていくためです。顧客の傾向が変わる、新しい商品やパターンが増える、世の中の状況が変わる——こうした変化に追従するには、定期的にデータを見直し、必要に応じて再学習させる作業が欠かせません。
つまりAI開発には、通常のシステム開発のような「完成・納品して終わり」がありません。この前提を見落とすと、「本番リリースまでの費用」だけを予算化し、リリース後の改善費用を見込み忘れる、という典型的な失敗に陥ります。
段階的内製化モデル（外注PoC→並走→内製主体）
「どこまで外注すべきか」という問いには、固定の正解はありません。むしろ重要なのは、外注と内製のバランスをフェーズに応じて動かしていくという発想です。1つのモデルとして、次のような段階的内製化が考えられます。
- 第1段階（外注主体）: PoC・MVPは知見のある外部ベンダーが主導し、自社は意思決定と評価に集中する。
- 第2段階（並走・ハイブリッド）: 本番リリース前後で、社内メンバーがベンダーと並走し、運用・改善の手順を学び取る。
- 第3段階（内製主体）: 日常の運用・小さな改善は社内で回し、難易度の高い改修や大きな方向転換のときだけ外部の力を借りる。
このように発注比率をフェーズで動かすと、初期は専門性を借りてスピードを出しつつ、後期は内製化でコストと依存度を下げる、という両取りが可能になります。内製と外注の判断をより詳しく検討したい場合は、AI開発の内製vs外注もあわせてご覧ください。
継続改善を外注し続ける場合の費用構造の注意点
段階的内製化が難しく、継続改善も外注し続ける選択をする場合は、費用構造に注意が必要です。
継続改善の外注は、月額の保守・運用契約という形を取ることが多く、本番リリースまでの一時的な開発費とは異なり、毎月・毎年積み上がる固定費になります。改善のたびに都度見積りで発注する形だと、依頼のリードタイムやコストが読めず、結果として「使い続けるほど割高になる」状況に陥りがちです。外注を続けるにしても、改善の範囲・頻度・費用をあらかじめ契約に織り込み、社内側でもAIの状態を把握できる最低限の仕組みは持っておくことをおすすめします。
フェーズ別「発注すべきもの」早見表
ここまで解説した4フェーズを、1枚の早見表に集約します。そのまま稟議資料のたたき台として転記できる粒度でまとめました。費用・期間は対象範囲やデータ規模によって変動するため、あくまで初期検討の目安として扱ってください。
項目 | PoC | MVP | 本番リリース | 継続改善 |
|---|---|---|---|---|
発注範囲 | 1業務に絞った精度検証・実現可能性の確認・成功条件の合意 | コア機能に絞った最小プロダクト・運用設計の初期版 | 非機能要件・セキュリティ・監視/監査ログ・本番移行計画 | 精度モニタリング・定期的な再学習・改善対応 |
主な成果物 | 評価レポート・検証コード・本番概算見積り・推奨構成案 | 動作する最小プロダクト・運用体制の初期設計・検証結果 | 本番システム・運用手順書・移行計画・設計ドキュメント | 改善レポート・モデル更新履歴・運用ログ |
費用・期間の目安 | 100万〜300万円／1〜3ヶ月 | プロジェクト規模により変動（本番の手前の中間段階） | PoCの数倍規模になることが多い | 月額の保守・運用費（継続的に発生） |
社内に残すもの | 続行/中止/再設計の判断・成功条件の言語化 | 検証したい仮説・運用担当者の目星 | 運用体制・受領した設計資料・改善の知見 | 日常運用・小改善の内製化ノウハウ |
次フェーズへの引き継ぎ | 本番概算見積り・推奨アーキテクチャ | 運用設計の初期版・本番に向けた品質ギャップの把握 | 安定稼働した本番環境・運用手順 | （内製比率を高めながら循環） |
この表の縦の列を1つずつ見れば「今どのフェーズの発注をしているか」が分かり、横の行を見れば「フェーズをまたいで何を社内に残すべきか」が分かります。
AI開発ロードマップを発注計画に落とすときの注意点
ロードマップを理解したら、最後にそれを実際の発注計画へ落とし込む際の実務上の注意点を押さえておきましょう。段階発注を成功させるかどうかは、発注者がどれだけ主導権を握り続けられるかにかかっています。
段階発注で発注者が握るべき3つの権利
段階発注で発注者の立場を守るために、契約段階で次の3つの権利を意識的に確保しておくことをおすすめします。
- 評価して見直す権利: フェーズが変わるたびに、同じベンダーに自動的に継続発注するのではなく、成果を評価したうえで継続するか見直すかを選べる状態にしておく。フェーズ間でいったん区切りを入れることが、この自由を生みます。
- 成果物を所有する権利: 各フェーズで作られたコード・データ・設計ドキュメントの所有権や受領範囲を契約で明記しておく。これが曖昧だと、ベンダーを変えたくても変えられない依存状態に陥ります。
- 次フェーズの見積りを得る権利: あるフェーズの発注時点で、次フェーズの概算見積りを成果物に含めるよう要求しておく。これにより、後出しの追加費用に振り回されず、予算計画を先に描けます。
この3つを握っておくと、「ベンダーの言いなりになるのではないか」という不安の大部分は解消されます。外注先そのものの選び方については、AI受託開発とはも参考になります。
ロードマップを社内稟議に通すための見せ方
社内稟議では、「総額いくらかかるのか分からないもの」は通りにくいものです。とはいえAI開発は、その性質上、最初から総額を確定できません。
ここで効くのが、まさにフェーズで区切る発注設計です。「まずPoCに100万〜300万円・1〜3ヶ月を投じ、その結果次第で本番フェーズに進むかを判断する」という見せ方であれば、稟議の承認者にとっても「小さく始めて、見極めてから本格投資する」という納得しやすいストーリーになります。本記事の早見表をそのまま添付し、フェーズごとに承認のチェックポイントを設ける形にすると、稟議は格段に通りやすくなります。
よくある質問
Q. AI開発のフェーズは何段階に分かれますか？ A. 本記事では、PoC（概念実証）・MVP・本番リリース・継続改善の4フェーズに整理しています。解説によっては「企画・構想 / PoC / 開発・実装 / 運用 / 改善」の5区分を使うこともありますが、発注の単位を考えるうえでは、検証（PoC）→ 最小プロダクト（MVP）→ 本番 → 改善という流れで捉えると分かりやすくなります。
Q. PoCとMVPの違いは何ですか？ A. PoCは「検証用」で製品化を前提とせず、実現可能か・精度が出るかを確かめるためのものです。一方MVPは「製品の最初のバージョン」で、実際に一部のユーザーが業務で使うことを前提とします。PoCで作ったものをそのまま本番品質として流用できるわけではない点に注意が必要です。
Q. AI開発のPoCの費用・期間の目安はどのくらいですか？ A. 検証範囲によって幅がありますが、おおむね費用100万〜300万円程度、期間1〜3ヶ月程度が一つの目安です。対象を1業務に絞れば100万円前後から始められるケースもあります（出典: 株式会社renue、2026年）。期間は長引くほど成功率が下がる傾向があるため、4〜8週間程度で区切る進め方が推奨されています。
Q. AI開発はどこまで外注すべきですか？ A. 「固定でここまで」という正解はなく、フェーズに応じて外注と内製の比率を動かすのが現実的です。初期のPoC・MVPは専門性のある外部に任せ、本番前後で社内メンバーが並走して学び、継続改善は徐々に内製主体へ移していく段階的内製化が、コストと依存度の両面でバランスが取りやすい進め方です。
Q. PoCが本番化しないのはなぜですか？ A. 主な原因は技術ではなく構造にあります。本番運用を担う人材・体制が社内にいない、改善のたびに外部依存が深まる、セキュリティやガバナンスが後付けになる——こうした要因が重なり、多くのプロジェクトが本番化に至らずに終わるとされています。前のフェーズから本番を見据えて引き継ぎを設計しておくことが対策になります。
Q. AI開発を最初から本番まで一括発注してもよいですか？ A. おすすめしません。AI開発は「やってみないと精度が読めない」性質があるため、一括発注すると精度が出ないまま本番開発を進めるリスクや、要件の変更による追加費用を発注者が抱え込むことになります。フェーズで区切り、各段階の終わりに続行・中止・再設計を判断できる段階発注のほうが安全です。
まとめ｜AI開発はフェーズで区切って発注する
AI開発は、通常のシステム開発のように要件を固めて一括発注するのではなく、PoC・MVP・本番リリース・継続改善の4フェーズに区切り、各段階で「何を発注し、何を社内に残すか」を設計することが成功の鍵です。
要点を改めて整理します。PoCは「成功」ではなく「続行・中止・再設計の判断材料」を最小投資で得る段階で、本番概算見積りまで成果物に含めることが次フェーズの主導権につながります。MVPは製品の最初のバージョンとしてコア機能に絞り、運用設計の初期版もここで描きます。本番リリースでは非機能・セキュリティ・運用体制を作り込み、前フェーズから引き継ぎを設計して「死の谷」を越えます。継続改善では、外注と内製の比率をフェーズで動かしながら、長期コストと依存度を最適化していきます。そして全フェーズを通じて、発注者は「評価して見直す権利」「成果物を所有する権利」「次フェーズの見積りを得る権利」を握り続けることが大切です。
次の一歩は、いきなり大きく構えず、まず小さくPoCから始めることです。本記事の早見表を稟議のたたき台に転記すれば、「小さく始めて見極めてから本格投資する」という承認者にとって納得しやすい計画を描けます。具体的な進め方や事例をさらに知りたい方は、中小企業のAI活用事例もあわせてご覧ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
