お役立ち情報
詳細設計とは？成果物の種類一覧から進め方・注意点までわかりやすく解説

システム開発お役立ち情報

公開日:2026.08.21　更新日:2026.08.21

詳細設計とは？成果物の種類一覧から進め方・注意点までわかりやすく解説

監修者

取締役斎藤裕一

詳細設計とは、システム開発において欠かせない工程の一つであり、基本設計で決まった仕様をプログラミングできる粒度まで具体化する作業を指します。しかし「どのような成果物を作成すべきか」「基本設計との違いは何か」が曖昧なまま進めてしまい、後工程で手戻りが発生するケースも少なくありません。

本記事では、詳細設計の目的や基本設計との違いを整理した上で、代表的な成果物の種類と役割、具体的な書き方、進め方、注意点まで体系的に解説します。

また、GeNEEでは詳細設計について分からないという方でも、システム開発について無料でご相談いただけます。要件定義から開発・実装まで一気通貫でご支援可能ですので、まずは30分の無料相談にぜひお申込みください。

詳細設計とは？目的と役割をわかりやすく解説

詳細設計はシステム開発において、実装工程の直前に行われる設計作業です。ここでは詳細設計の定義を確認した上で、目的・役割・開発工程全体での位置づけを順に解説します。

詳細設計の目的

詳細設計の目的は、基本設計で決まったシステム仕様をプログラマーが実装できるレベルまで具体化することです。基本設計では「何を作るか」を定義しますが、詳細設計では「どう作るか」を明確にします。

たとえばECサイトの注文機能の場合、基本設計の段階では「ユーザーが商品をカートに入れて注文できる」という機能要件を定めます。一方、詳細設計ではカートへの追加処理のフロー、在庫チェックのタイミング、決済APIとの連携方法など、コードに落とし込める粒度まで設計します。

ただし、こうした検討結果を担当者の頭の中だけにとどめてしまうと、複数人で開発を進める過程で認識のずれが生じかねません。そのため、処理フローやデータの流れを設計書として文書化し、開発チーム全体で共有することが求められます。なお、設計書のフォーマットはプロジェクトや企業ごとに異なるため、チーム内で統一ルールを定めておくことが重要です。

詳細設計の役割

詳細設計の役割は、基本設計の内容を開発者の視点で整理し、プログラマーが迷わず実装に着手できる状態を作ることであり、顧客の要望とシステム開発をつなぐ「橋渡し」の役割を果たす点にあります。

詳細設計が適切に行われていれば、プログラマーごとの解釈のばらつきが減り、品質の均一化が可能です。チームの中で共通の判断基準ができるため、レビューの効率も向上します。

また、設計段階で処理の矛盾や抜け漏れを発見できれば、実装後に発覚するよりも修正コストを大幅に抑えられます。反対に、詳細設計が不十分なまま実装に進んでしまうと、コードの書き直しやテスト工程での大幅な修正が必要になるリスクも高まってくるため、詳細設計は開発プロジェクト全体のコストとスケジュールを大きく左右する工程だと言えるでしょう。

システム開発工程における詳細設計の位置づけ

システム開発の工程は、採用する開発手法によって区切り方や呼び方が異なります。詳細設計がどこに位置づけられるかも手法ごとに変わってくるため、まずは代表的な開発手法における工程の対応関係を表で確認しておきましょう。

開発手法	工程の流れ	詳細設計の位置づけ
ウォーターフォール型	要件定義→基本設計→詳細設計→実装→テスト	基本設計のアウトプットを受け取り、実装工程へのインプットとなる成果物を作成する中間工程
V字モデル	要件定義⇔運用テスト、基本設計⇔結合テスト、詳細設計⇔単体テストというように、開発工程とテスト工程が対応する	単体テストの検証項目の根拠となる工程であり、設計の精度がテスト品質に直結する
アジャイル開発	イテレーション（スプリント）単位で要件定義からテストまでを短いサイクルで繰り返す	工程を厳密には分けないが、実装前に「何をどう作るか」を整理する考え方自体は各スプリント内で踏襲される

詳細設計は、ウォーターフォール型の開発工程では要件定義→基本設計→詳細設計→実装→テストという流れの中に位置します。基本設計のアウトプットを受け取り、実装工程へのインプットとなる成果物を作成する中間的な工程です。

また、V字モデルの観点では、詳細設計は後工程の単体テストと対になる関係にあります。詳細設計で定義した処理ロジックや条件分岐が、単体テストの検証項目の根拠となるため、設計の精度がそのままテスト品質に直結します。この対応関係を意識して設計書を作成することで、テスト工程での検証漏れを未然に防ぐことが可能です。

なお、アジャイル開発ではウォーターフォールのように工程を厳密に分けないケースもありますが、設計の考え方自体は共通しています。

関連記事：システム開発とは？種類や開発工程などを詳しく紹介

詳細設計と基本設計の違い

詳細設計と基本設計は混同されやすい工程ですが、視点・目的・成果物が明確に異なります。ここでは「外部設計」「内部設計」との関係も含めて、両者の違いを整理します。

基本設計（外部設計）の概要

基本設計とは、ユーザーの視点からシステムの挙動を定義する工程です。「外部設計」とほぼ同義で使われる場合が多く、画面設計・帳票設計・データベースの論理設計など、利用者が直接触れる領域を扱います。

基本設計の成果物はクライアントにも共有され、レビューを経て合意を形成する点が特徴です。つまり、基本設計はシステムの「見える部分」を設計する工程だと言えます。基本設計を作成する際は、ライアントとの認識のずれを防ぐために、図表やプロトタイプを活用して視覚的に伝えることが重要です。仮に基本設計の段階でクライアントとの合意が不十分な場合、後続の詳細設計や実装にまで影響が及ぶので、認識のずれが発生しないための丁寧なコミュニケーションが欠かせません。

詳細設計（内部設計）の概要

詳細設計とは、開発者の視点からシステムの内部構造を設計する工程です。「内部設計」とほぼ同義で扱われ、基本設計で定まった要件を「どう実装するか」まで具体化します。

たとえば、基本設計で「郵便番号を入力すると住所が自動入力される」と定義された場合、詳細設計ではAPIの呼び出し先、レスポンスデータのパース方法、エラー時のフォールバック処理、入力値のバリデーション仕様まで設計します。

詳細設計の成果物は、主に社内の開発チーム向けであり、クライアントに開示しないケースが一般的です。ただし、大規模プロジェクトではクライアント側に技術担当者がいる場合もあり、その際はレビュー対象に含まれることもあります。

基本設計と詳細設計の主な違い【比較表】

以下の表は、基本設計と詳細設計の違いを主要な観点で整理したものです。

比較項目	基本設計（外部設計）	詳細設計（内部設計）
主な視点	ユーザー視点	開発者視点
目的	「何を作るか」を定義	「どう作るか」を定義
主な成果物	画面設計書、DB論理設計書等	クラス図、シーケンス図、DB物理設計書等
対象読者	クライアント・発注者	開発チーム（プログラマー）
クライアント開示	あり（レビュー対象）	なし（社内管理が中心）

このように、基本設計は「ユーザーにとって何ができるか」を定義し、詳細設計は「開発者がどう実装するか」を定義する工程です。両者はシステム開発の品質を支える車の両輪のような関係にあります。

詳細設計の主な成果物一覧

詳細設計では多種多様な成果物が求められます。プロジェクトの規模や開発手法によって必要なドキュメントは異なりますが、ここでは代表的な成果物を「構造系」「振る舞い系」「データ・処理系」「テスト系」の4カテゴリに分類して紹介します。

成果物の全体像【分類表】

まず、詳細設計で作成される主な成果物の全体像を、以下の表で種類別に整理して確認しましょう。

分類	主な成果物
構造を示す成果物	クラス図、モジュール構造図
振る舞いを示す成果物	シーケンス図、アクティビティ図、状態遷移図、画面遷移図
データ・処理系の成果物	DB物理設計書、入出力設計書、バッチ処理設計書、外部IF設計書、IPO
テスト関連	テスト設計書

それぞれのカテゴリについて、代表的な成果物の役割と特徴を解説します。

構造を示す成果物（クラス図・モジュール構造図）

システムの静的な構造を可視化する成果物として、「クラス図」「モジュール構造図」が挙げられます。プログラムの全体構成を把握し、作業分担や開発の優先順位を決める際に活用しましょう。

クラス図

クラス図は、システムを構成するクラスの属性・操作・関係性を表した設計図です。オブジェクト指向開発では最も基本的な成果物であり、インターフェース設計書や入出力設計書とも密接に関連します。クラス間の依存関係を明確にすることで、影響範囲の特定や修正時の判断材料として役立つため、設計の初期段階で主要なクラスを洗い出しておくと、実装フェーズでの手戻りを抑えられます。

モジュール構造図

モジュール構造図は、システムを構成する各モジュールの分割構造と相互関係を示す設計図です。モジュール同士の関係を線で結ぶため視覚的にわかりやすく、開発全体の見通しを立てる際に利用します。モジュール数が増えるほど依存関係も複雑になり、全体像を把握しないまま作業を進めると影響範囲の見落としにつながりやすいため、大規模なシステムほどこの成果物の重要度が高まります。

振る舞いを示す成果物（シーケンス図・アクティビティ図・状態遷移図・画面遷移図）

システムの動的な挙動や処理の流れを表現する成果物です。時間軸に沿った処理順序や、ユーザー操作に対するシステムの応答を可視化します。

シーケンス図

シーケンス図は、オブジェクト間のメッセージのやり取りを時間軸に沿って表現する設計図です。アクティビティ図より粒度が細かく、クラスやオブジェクト間の具体的な処理連携を定義します。API呼び出しの順序やレスポンスの流れを把握する際に欠かせない成果物です。複雑な処理では正常系と異常系を分けて作成すると読みやすくなります。

アクティビティ図

アクティビティ図は、ユーザー操作とシステム処理の全体的な流れを可視化する設計図です。フローチャートと同様の記法で表現でき、フロントエンドとバックエンドの処理分担を明確にします。シーケンス図と対で使われることが多く、処理の全体像を俯瞰する際に有効な成果物です。

状態遷移図

状態遷移図は、システムの状態変化を図形と矢印で表現した設計図であり、「状態名」「遷移」「イベント」の3要素で構成されます。すべての状態変化パターンを網羅的に記録するため、テスト工程での抜け漏れ防止に役立ちます。特にステータス管理が複雑な業務システムでは、この成果物の重要度が高くなります。

画面遷移図

画面遷移図は、Webアプリケーションや業務システムにおける画面間の遷移を表した設計図です。各画面の責任部門を明確にできるほか、完成後のユーザーマニュアル作成やサポート体制の検討にも活用されます。

データ・処理に関する成果物

データベースやファイルの物理構造、バッチ処理や外部システム連携など、データフローと処理ロジックを定義する成果物であり、システムの裏側を支える重要なドキュメント群に当たります。

データベース物理設計書

データベース物理設計書は、論理設計（ER図ベース）を実際のDB環境に適用するための設計書です。テーブルのインデックス付与やデータ型の決定、想定データ量に基づくストレージのスペック設計などを含みます。パフォーマンスに直結する成果物であるため、運用開始後のデータ増加やアクセスパターンの変化も見据えた設計が必要です。

入出力設計書

入出力設計書は、各機能のインプット情報とアウトプット情報を定義する設計書です。画面設計書と連動し、画面上の入力項目の制御仕様や出力項目のフォーマットを記載します。バリデーションルールやエラー時の表示仕様も含めて定義しておくと、実装時の判断に迷うことが減ります。画面ごとに入出力項目の一覧を整理しておくと、テスト工程でのチェックリスト作成にも活用可能です。

バッチ処理設計書

バッチ処理設計書は、夜間自動処理やシステムの裏側で動く自動処理を定義する設計書です。入力・加工・出力の3つのフェーズに分けて検討し、トリガー定義（定時起動またはイベント起因）や並列処理の可否なども記載します。障害発生時のリカバリ手順やリトライ方針まで盛り込んでおくと、運用開始後のトラブル対応をスムーズに実施可能です。

外部インターフェース設計書

外部インターフェース設計書は、社内外の他システムとの連携仕様を定義する設計書です。接続先・通信プロトコル・連携タイミング・インターフェース項目仕様・認証方式・例外処理などを整理します。連携先のシステム変更に伴う影響を受けやすいため、バージョン管理を徹底しておくことが重要です。連携テストの計画を詳細設計の段階で盛り込んでおくと、結合テスト工程での手戻りを防ぎやすくなります。

IPO（処理機能記述書）

IPOは、各機能の処理内容をInput・Process・Outputの3形式で表現した設計図です。処理のロジックを重視したい場合に適しており、修正時の影響範囲の特定や工数の試算にも活用できます。シーケンス図と組み合わせて使用すると、処理の全体像と詳細の両方を把握しやすくなります。

テスト設計書

テスト設計書は、単体テスト・結合テストの指針と詳細な検証項目を定める成果物です。テスト設計書作成では「誰が実施しても迷わない」「誰が実施しても結果が同じになる」「合否が明確に判定できる」の3点が満たされることを目指します。

また、テスト設計書を作成する際は、正常系だけでなく異常系やエッジケースも網羅的に定義することが重要です。境界値や例外処理のパターンを漏れなく記載しておくことで、テスト工程での品質が向上します。また、テスト設計書の項目を詳細設計と同時並行で作成すると、設計の抜け漏れを早期に発見しやすくなるメリットもあるので、できる限り並行で確認しながら進めると良いでしょう。

詳細設計の進め方と設計書作成のポイント

詳細設計は大きく「基本設計の具体化」と「設計書の作成・レビュー」の2ステップで進めます。ここではそれぞれの進め方と、わかりやすい設計書を作るためのポイントを紹介します。

ステップ1：基本設計の読み込みと具体化

まず、チームメンバー全員で基本設計書を読み込み、認識を合わせるところから始めます。各機能を開発者の視点で確認し、プログラミングできるレベルまで一つずつ落とし込んでいきましょう。

この段階で、複数の機能で共通して使えるオブジェクトやモジュールがないかを洗い出しておくと、後の実装で無駄な重複を減らせます。基本設計の不明点は、後回しにすると手戻りが発生する原因となるため、早い段階で設計者やクライアントに確認することが重要です。認識合わせの結果は議事録として残しておくと、後から参加したメンバーへの情報共有にも活用できます。

ステップ2：詳細設計書の作成とレビュー

検討結果を成果物としてまとめる際は、開発者目線でわかりやすく、かつ一意に解釈できる記述を心がけましょう。図や表を適切に活用し、文章だけでは伝わりにくい処理の流れを可視化することも大切です。

作成後は必ず他のメンバーからレビューを受けましょう。レビューは最低でも2名以上で実施することで、設計者本人では気づきにくい観点を補完できます。特に実装を担当するプログラマーにレビューに参加してもらうと、実装視点でのフィードバックが得られて効果的です。レビューで指摘された欠陥や不足は速やかに反映し、記録を残しておくことで、設計の精度を高めつつ後から変更理由の追跡もできます。

わかりやすい設計書を書くためのコツ

品質の高い詳細設計書を作成するためには、以下のポイントを意識することが効果的です。

曖昧な表現を避けること：「適宜処理する」「必要に応じて対応する」のような記述は、読み手によって解釈が変わる原因となります。処理の条件や手順は数値や固有名詞を使って具体的に記載することが大切です。
図や表を効果的に活用すること：複雑な処理フローや条件分岐は、文章だけで記述すると理解しにくくなります。シーケンス図やフローチャートを用いると、視覚的に把握しやすくなります。
命名規則やフォーマットをプロジェクト全体で統一すること：設計書のテンプレートや用語集を事前に整備しておくと、複数人で分担して作成しても一貫性を保てます。設計の意図（なぜこの方式を選んだか）もコメントとして残しておけば、将来的な保守フェーズで役立てることも可能です。

詳細設計の書き方

詳細設計の成果物は種類が多く、それぞれに適した書き方があります。ここでは代表的な成果物について、実際にどのような手順で作成するのかを具体的に解説します。初めて詳細設計を担当する方は、各成果物の基本的な構造を理解した上で着手すると、スムーズに作成を進められるでしょう。

クラス図の書き方

クラス図は、「クラス名」「属性」「操作」を1つの矩形にまとめて表現し、クラス間を線でつなぐことでシステムの構造を視覚的に示します。まずシステム全体から主要なクラスを洗い出し、各クラスが持つデータ（属性）と処理（操作）を定義しましょう。

次に、クラス間の関係性を「関連」「集約」「継承」などのUML記法で記述します。関係の多重度（1対1、1対多など）も明記しておくと、データベース設計や実装時のコレクション設計に直結するため、後工程での手戻りを減らせます。作成したクラス図はチーム内でレビューし、責任範囲の偏りや依存関係の複雑さがないかを確認しておくとよいです。

シーケンス図の書き方

シーケンス図は、処理の登場人物（オブジェクト）を上部に横並びで配置し、時間軸を縦方向に取って、やり取りを矢印で記述します。まず対象とする機能やユースケースを1つ選び、関連するオブジェクトを特定します。

その後、処理の開始から終了までのメッセージを時間順に記述していく。条件分岐がある場合は「alt」フレーム、繰り返しがある場合は「loop」フレームを使って表現するとよいだろう。戻り値も破線矢印で明記しておけば、処理の全体像が把握しやすくなる。正常系と異常系を分けて記述すると、さらに読みやすい成果物に仕上がるはずだ。1つのシーケンス図が複雑になりすぎる場合は、機能ごとに分割して複数枚で管理するのも有効な方法である。

データベース物理設計書の書き方

データベース物理設計書は、論理設計で定めたエンティティを実際のテーブルに変換し、物理レベルの仕様を記述する設計書です。テーブル名・カラム名・データ型・桁数・NULL許可の有無・主キー・外部キーなどの情報を、テーブル定義書として整理していく。

加えて、検索性能を考慮したインデックスの設計や、想定データ量に基づくパーティション方針も記載しておくと、運用開始後のパフォーマンス問題を事前に回避しやすくなるだろう。テーブル間のリレーションはER図と突き合わせて整合性を確認しておきたい。命名規則（テーブル名やカラム名の付け方）をプロジェクト内で統一しておけば、複数人での開発でも混乱を防げる。

詳細設計の成果物を作成する際の注意点

詳細設計はシステムの品質を左右する重要な工程です。ここでは、成果物を作成する際に意識すべきポイントを紹介します。

属人化が発生し、共有されにくい

詳細設計を含むシステム開発の設計工程では、ドキュメント作成に関する明確なルールが定められていないケースが多いです。その結果、設計書の粒度や書き方が担当者の裁量に委ねられ、属人化が発生しやすくなります。

また、設計書を個人のローカル環境で管理していると、チームメンバーがリアルタイムで参照・更新できないという問題も起こります。

属人化を防ぐには、SubversionやDropboxなどのバージョン管理ツール、あるいはクラウドストレージを活用し、常に最新版をチーム全体で共有できる体制を整えることが大切です。テンプレートや記載ルールをプロジェクト初期段階に標準化しておくことで、属人化のリスクも軽減できるほか、新しいメンバーが参画した際のキャッチアップの時間を短縮できます。設計書のフォーマットだけでなく、用語の定義や略語の一覧も合わせて整備しておくと、チーム内での認識のずれを未然に防ぐことにもつながるでしょう。

変更時の工数負担を考慮する

詳細設計では、要件の追加や仕様変更に伴い設計変更が頻繁に発生します。場合によっては、既に完了した成果物を根本から見直す必要が出てくることもあります。

変更が発生した際の影響範囲を把握しやすくするためにも、成果物間のトレーサビリティ（追跡可能性）を確保しておくことが重要です。

変更履歴を一覧で管理できるシートをの初期段階で整えておくと、工数の増大を最小限に抑えられるほか、振り返りの際にも活用可能です。変更のたびに関連する成果物を洗い出し、漏れなく更新する運用を徹底することが、品質の維持につながります。

要件定義との整合性を定期的に確認する

詳細設計では細かな仕様の検討に集中するあまり、本来の要件定義からずれてしまうリスクがあります。担当者が「この方がよいだろう」と独自に判断した結果、要件にない機能を追加してしまう場合もあります。

このようなスコープクリープを防ぐためにも、定期的に要件定義書と照合し、本来の要件から逸脱していないかをチェックする習慣が大切です。チーム内でのレビューの場を活用し、第三者の目線で確認する仕組みを作ることが効果的です。要件定義との紐づけを成果物ごとに管理しておくと、変更時の影響範囲も特定しやすくなります。

実現可能性（Can Beモデル）を検証する

詳細設計の次の工程として「実装」が控えており、この段階までに設計が実現可能なレベルにあるかを検証しておく必要があります。

具体的には、工数の精査・システムスペックの確認・ビジネスロジックの机上検証を行い、設計通りに実装できるかを判断します。設計段階で実現が難しいと判明した箇所は、代替案を検討して設計に反映しておくことで、実装工程での手戻りを未然に防ぐことが可能です。技術的に新しい要素がある場合は、プロトタイプを作成して事前に検証しておくことも有効な手段です。

また、機能面の仕様だけでなく、性能・セキュリティ・可用性といった非機能要件も詳細設計の段階で具体化しておく必要があります。アクセス集中時のレスポンス要件やデータの暗号化方式など、見落としやすい項目も少なくありません。IPAの『非機能要求グレード』などのフレームワークを活用して体系的に洗い出しておくと、設計段階での抜け漏れを効果的に防げます。

詳細設計に関するFAQ

詳細設計について、よくある質問とその回答をまとめます。

基本設計との違いは？

基本設計と詳細設計の境界はプロジェクトの規模や契約形態によって異なります。小規模な案件では基本設計と詳細設計を一体で進めるケースもあれば、大規模な案件では工程を厳密に分けて別チームが担当することもあります。自社のプロジェクトでどこまでを基本設計に含め、どこから詳細設計とするかを事前にチーム内で合意しておくことが大切です。

何をどこまで書くべき？

プログラマーが設計書だけを見て実装に着手できるレベルが目安です。処理の条件分岐やエラーハンドリング、データの型や桁数まで明記することで、実装時の迷いや認識のずれを防げます。ただし、過度に細かく書きすぎると変更時のメンテナンスコストが増えるため、バランスを意識することも大切です。実務では「新人プログラマーが読んでも実装できるか」を基準にすると、適切な粒度を判断しやすくなります。

詳細設計書は不要ですか？

アジャイル開発など一部の開発手法では、詳細設計書を省略するケースもあります。ただし、チーム間の引き継ぎや保守・運用フェーズを考えると、設計の意図を記録した文書は長期的に必要です。省略する場合でも、最低限の設計メモやコード内コメントで設計の意図を残しておきましょう。特にチームの入れ替わりが想定されるプロジェクトでは、設計書の有無が引き継ぎの効率に大きく影響します。

詳細設計は誰が担当する？

一般的には、SE（システムエンジニア）やリードエンジニアが担当するケースが多いです。基本設計の内容を正しく理解した上で、実装に落とし込むスキルが求められるポジションのため、プロジェクトの規模によっては実装担当のプログラマーが兼務することもあります。近年では、設計とコーディングを並行して進めるフルスタックエンジニアが詳細設計を担当するケースも増えています。

なお、発注者側が詳細設計を担当することは、基本的にはありません。ただし、詳細設計がどのような中身で、何を目的として構成されているかは発注者側も把握しておくことで、開発者側との認識ずれが発生しづらくなります。

詳細設計にかかる期間の目安は？

プロジェクトの規模や複雑さによって大きく変わりますが、中規模のシステム開発であれば2週間から1か月程度が一つの目安です。成果物の数やレビューの回数によっても変動するため、スケジュールにはバッファを持たせておくことが重要です。初めて詳細設計を行うチームの場合は、経験者のサポートやテンプレートの活用により、所要期間を短縮できることもあります。

まとめ

本記事では、詳細設計とは何かという基本的な定義から、基本設計との違い、代表的な成果物の種類と役割、具体的な書き方、進め方のステップと注意点までを解説しました。

詳細設計は基本設計の内容を開発者視点で具体化する工程であり、クラス図やシーケンス図、データベース物理設計書など多様な成果物が求められます。品質の高い設計書を作成するには、属人化の防止や要件定義との整合性チェック、実現可能性の検証が欠かせません。

詳細設計の精度を高めることが、後工程の実装やテストの品質向上につながります。まずは自社のプロジェクトに合った成果物を選定し、テンプレートの整備から始めてみてはいかがでしょうか。

監修者

斎藤裕一
取締役

＜略歴＞
大阪大学工学部、大阪大学大学院情報科学研究科修了。
国内最大手IT企業の株式会社NTTデータで大手金融機関向けに債権書類電子化システム、金融規制・法規制対応システムの要件定義・インフラ設計・開発・構築・複数金融サービスのAPI連携等を手がける。その後、株式会社GeNEEの取締役に就任。

＜資格＞
基本情報技術者試験、応用情報技術者試験、Oracle Master Platinum等多数

この記事をいいねと思ったら！