「モックって何？」と聞かれて、なんとなく「試作品っぽいやつ」と答えて終わっていないでしょうか。正直、それだと半分しか当たっていません。モックはデザインにも出てくるし、プログラミングのコードにも普通に出てきます。しかも、現場では当たり前のように使われます。初心者にだけ説明を省くという、人間社会おなじみの不親切設計です。
結論から言えば、モックとは「本物の代わりに使う仮のもの」です。画面デザインのモックなら、実際のサービスっぽく見せる仮の画面。コードのモックなら、本物のAPI・データベース・関数の代わりに使う仮の処理です。
私は最初、「モック＝見た目だけの画面」だと思っていました。しかし、コードを書いたりテストを触ったりすると、「モックAPI」「モック関数」「モックデータ」という言葉が平気な顔で出てきます。ここを理解しないまま進むと、開発の会話が一気に霧の中になります。霧どころか、名前だけ立派な落とし穴です。
モックとは？一言で言えば「本物の代役」
モックの基本的な意味
モックとは、本物の代わりに使う「仮のもの」「模造品」「それっぽく作ったもの」です。英語の mock には「まねる」「模造の」「見せかけの」といった意味があります。
ITやデザインの現場で使うモックは、悪い意味の偽物ではありません。むしろ、本物をいきなり作る前に、見た目・動き・処理・使い勝手を確認するための便利な代役です。
たとえば、家を建てる前に模型を作ることがあります。いきなり土地に巨大な家を建ててから「玄関の位置が気に入らない」と言い出したら、もはや人間の愚かさの記念碑です。だから先に模型で確認します。Webサイトやアプリ、コードでも同じです。いきなり本番を作るのではなく、まずモックで確認するわけです。
モックアップとの違い
モックとよく似た言葉に「モックアップ」があります。実際にはかなり近い意味で使われることも多いです。
モックアップは、完成品の見た目を確認するための模型や画面イメージを指すことが多いです。Webサイトなら、ボタン・画像・文字・余白などを配置して、「完成したらこんな見た目になります」と示すものです。
一方で、モックはもっと広い言葉です。デザインの見た目だけでなく、コード上の仮処理、仮データ、仮APIなどにも使われます。
つまり、ざっくり言うならこうです。
モックアップは「見た目確認用の仮デザイン」
モックは「本物の代わりに使う仮のもの全般」
この理解でかなり迷いにくくなります。
ワイヤーフレーム・プロトタイプとの違い
モックを理解するときに、ワイヤーフレームやプロトタイプとの違いも押さえておくべきです。ここをごちゃ混ぜにすると、打ち合わせで全員が違うものを想像しながら同意するという、なかなか地獄みたいな状態になります。
ワイヤーフレームは、画面の骨組みです。色や細かいデザインよりも、「どこに何を置くか」を確認するものです。
モックアップは、より完成形に近い見た目の確認用デザインです。色、画像、余白、ボタンの雰囲気なども入ります。
プロトタイプは、実際にクリックしたり画面遷移を確認したりできる試作品です。Figmaでもプロトタイプ機能を使えば、ユーザーがどのように操作するかを確認する流れを作れます。
つまり、流れとしては以下のように考えるとわかりやすいです。
ワイヤーフレーム：骨組み
モックアップ：見た目の完成イメージ
プロトタイプ：操作感まで確認できる試作品
コードのモック：本物の処理の代役
コードにもモックはあるのか？
答えは「ある」。むしろテストではかなり重要
コードにもモックはあります。しかも、ただの飾りではありません。テストコードではかなり重要です。
コードにおけるモックとは、本物の関数・クラス・API・データベースなどの代わりに使う仮の部品です。本物を呼び出すと面倒だったり、時間がかかったり、外部サービスに依存したりする場合に使います。
たとえば、ユーザー情報を取得する処理をテストしたいとします。本番では外部APIにアクセスする設計だとします。しかしテストのたびに本物のAPIへアクセスしていたら、通信環境に左右されます。API側の障害にも巻き込まれます。料金がかかることすらあります。そんなものを毎回テストで叩くのは、床掃除のたびに家を建て替えるようなものです。
そこでモックを使います。
「APIがこう返したことにする」
「データベースにこの値が入っていたことにする」
「この関数はこの結果を返すことにする」
こうやって、本物の処理を使わずにテストできます。
JavaScriptのモック例
たとえば、JavaScriptのテストで有名なJestでは、モック関数を作れます。Jest公式でも、モック関数は実際の実装を消して、呼び出し内容や戻り値をテスト用に扱えるものとして説明されています。
function getUserName(userApi, id) {
const user = userApi.findUser(id);
return user.name;
}
test('ユーザー名を取得できる', () => {
const mockApi = {
findUser: jest.fn().mockReturnValue({ name: 'Taro' })
};
const result = getUserName(mockApi, 1);
expect(result).toBe('Taro');
expect(mockApi.findUser).toHaveBeenCalledWith(1);
});
この例では、本物のAPIは使っていません。mockApi という仮のAPIを作り、findUser が呼ばれたら { name: 'Taro' } を返すようにしています。
これがコードにおけるモックです。
本物のAPIを呼ばずに、「APIがこう返した場合、この関数は正しく動くか」を確認しています。かなり実用的です。見た目だけの飾りではありません。
Pythonにもモックはある
Pythonにも unittest.mock という標準ライブラリがあります。Python公式ドキュメントでも、テスト対象システムの一部をモックオブジェクトで置き換え、その使われ方を確認できるものとして説明されています。
たとえば、外部サービスを呼ぶ処理を本当に実行せず、テスト中だけ仮の返り値を使うことができます。
from unittest.mock import Mock
def get_user_name(user_api):
user = user_api.find_user(1)
return user["name"]
mock_api = Mock()
mock_api.find_user.return_value = {"name": "Taro"}
result = get_user_name(mock_api)
assert result == "Taro"
mock_api.find_user.assert_called_once_with(1)
このコードでも、本物の user_api は使っていません。モックが代わりに動いています。さらに、find_user が本当に呼ばれたかどうかも確認できます。
この「呼ばれたかどうかを確認できる」という点が、ただの仮データとは違うところです。モックは、返り値を用意するだけでなく、呼び出しの検証にも使えます。
モックを使う理由
本物の処理を使うとテストが不安定になるから
モックを使う大きな理由は、テストを安定させるためです。
外部API、決済システム、メール送信、データベース、ファイル操作などを毎回本物で動かすと、テストが不安定になります。通信が遅い、APIが落ちている、データが変わった、メールが本当に送られてしまった。こういう事故が普通に起きます。普通に起きるのがもう嫌です。
モックを使えば、外部環境に左右されずに、自分のコードだけを確認できます。
たとえば、「決済が成功した場合」「決済が失敗した場合」「通信エラーになった場合」を自由に再現できます。本物の決済サービスで毎回失敗パターンを作る必要はありません。財布にも精神にも優しいです。
開発途中でも先に作業できるから
モックは、開発途中にも役立ちます。
たとえば、フロントエンド担当が画面を作りたいのに、バックエンドAPIがまだ完成していないことがあります。現実の開発では珍しくありません。むしろ予定通り全部そろう方が幻想です。
このとき、モックAPIを用意すれば、バックエンドが未完成でもフロントエンドの開発を進められます。
仮に以下のようなデータを返すAPIがあることにして、画面を作るわけです。
{
"id": 1,
"name": "Taro",
"plan": "premium"
}
本物のAPIが完成する前に、画面の表示やエラー処理を作れます。これができると、開発の待ち時間が減ります。人間同士の「まだですか？」という不毛なやり取りも少し減ります。
危険な処理を本当に実行しなくて済むから
モックは危険な処理を避けるためにも使います。
たとえば、以下のような処理を本当に実行したくない場面があります。
メール送信
決済処理
在庫更新
ユーザー削除
外部APIへの大量アクセス
本番データベースの更新
テストのたびに本当にメールが送られたら迷惑です。決済が走ったら最悪です。ユーザー削除が実行されたら、もはやテストではなく事件です。
だからモックで置き換えます。
「メール送信処理が呼ばれたことだけ確認する」
「決済成功として扱う」
「データ削除は実行せず、削除関数が呼ばれたかだけ確認する」
このように、本物を動かさずに安全に確認できます。
モック・スタブ・フェイク・スパイの違い
初心者はまずざっくりでいい
コードのテストを学び始めると、モック、スタブ、フェイク、スパイという言葉が出てきます。ここで心が折れる人は多いです。命名した人たちには一度、初心者向け資料を読んで反省してほしいところです。
ただ、最初から厳密に覚える必要はありません。ざっくり理解で十分です。
スタブは、決まった値を返す仮の部品です。
モックは、呼び出されたかどうかの検証にも使う仮の部品です。
フェイクは、本物より簡易的に動く実装です。
スパイは、本物の動きを一部使いながら、呼び出しを監視するものです。
実務では「モック」とまとめて呼ばれることも多い
実務では、厳密にはスタブでも、会話上は「モック」と呼ばれることがあります。
たとえば、「APIのモック作っておいて」と言われた場合、それは「本物のAPIの代わりに仮のレスポンスを返すものを作って」という意味かもしれません。厳密なテスト用語としてのモックではない可能性もあります。
ここが面倒なところです。モックという言葉は、かなり広く使われます。
だから現場では、「見た目のモックですか？」「APIのモックですか？」「テストコード上のモックですか？」と確認した方が安全です。確認しないまま進めると、完成後に「思ってたのと違う」と言われます。人類の伝統芸能です。
モックを使う場面
Webデザインやアプリデザイン
Webデザインやアプリデザインでは、完成形に近い画面を見せるためにモックを作ります。
たとえば、トップページ、ログイン画面、商品ページ、管理画面などを、実際に完成したような見た目で作ります。この段階では、裏側の処理はまだ動かなくても構いません。重要なのは、見た目や情報設計が伝わることです。
デザインのモックがあると、依頼者やチームメンバーが完成イメージを共有しやすくなります。文章だけで「シンプルで高級感のある感じ」と言われても、人によって想像が違います。シンプルの意味すら人間ごとに違います。困った生き物です。
モックを見せれば、「ボタンはここ」「画像はこのサイズ」「余白はこのくらい」と具体的に確認できます。
フロントエンド開発
フロントエンド開発では、モックデータやモックAPIがよく使われます。
本物のAPIがまだ完成していないときでも、仮のJSONデータを用意すれば画面を作れます。エラー時の表示、読み込み中の表示、データが空の場合の表示も試せます。
特にアプリ開発では、「データが1件のとき」「100件あるとき」「0件のとき」で画面の見え方が変わります。モックデータを作っておけば、そうしたパターンを先に確認できます。
バックエンド開発とテスト
バックエンド開発では、外部サービスやデータベースの代わりにモックを使うことがあります。
たとえば、決済サービス、メール配信サービス、クラウドストレージなどです。これらを毎回本物で動かすと、時間もお金もリスクも増えます。
テストでは、モックを使って「この条件なら成功する」「この条件ならエラーになる」といった状態を作れます。自分のコードが正しく反応するかを確認するには、非常に便利です。
モックの注意点
モックを信じすぎると本番で壊れる
モックは便利ですが、信じすぎると危険です。
モックはあくまで仮の代役です。本物と完全に同じではありません。モックでは成功するのに、本物のAPIにつないだら失敗することがあります。
たとえば、モックデータでは name が必ず入っていたのに、本番APIでは name が空の場合があります。モックでは通信エラーが起きなかったのに、本番ではタイムアウトすることがあります。
モックだけで安心するのは危険です。訓練用の木刀で強くなった気になって、真剣勝負に出るようなものです。かなり痛い目を見ます。
本物に近いモックを作る必要がある
モックを作るなら、本物に近づけるべきです。
APIのレスポンス形式、エラーパターン、データの型、空データ、異常値などをできるだけ本物に合わせます。都合のいい成功パターンだけ作っても、現実には弱いです。
特に、以下のパターンは用意しておくべきです。
正常なデータ
空のデータ
一部欠けたデータ
エラー
通信遅延
権限エラー
このあたりを確認しておくと、後で慌てにくくなります。
モックだらけにするとテストの意味が薄くなる
モックを使いすぎるのも問題です。
何でもかんでもモックにすると、「モック同士が予定通り動いているだけ」のテストになります。本物のコードが本当に連携できるかはわかりません。
テストにはバランスが必要です。
細かい単体テストではモックを使う。
全体の流れを見る結合テストでは本物に近い環境を使う。
最後は本番に近い状態で確認する。
このように役割を分けるべきです。
モックとは何かを一言でまとめる
モックは「本物っぽく見せる仮の代役」
モックとは、本物の代わりに使う仮のものです。
デザインでは、完成画面の見た目を確認するために使います。
開発では、未完成のAPIやデータの代わりに使います。
テストコードでは、本物の関数・クラス・外部サービスの代わりに使います。
つまり、「モックとは？」への答えは、場面によって少し変わります。ただし、中心にある考え方は同じです。
本物をいきなり使うと大変だから、仮の代役を使って先に確認する。
これがモックです。
コードにもモックはある。むしろ重要
コードにもモックはあります。特にテストコードでは重要です。
Jest、Pythonの unittest.mock、JavaのMockitoなど、多くの開発環境でモックは普通に使われています。モックを使うことで、外部APIやデータベースに依存せず、自分のコードの動きを確認できます。
初心者のうちは、「モック＝画面デザインのこと」と思いがちです。しかし、それだけでは足りません。コードにもモックはあります。むしろ、開発現場ではコードのモックを理解していないと、テストやAPI連携の話で置いていかれます。
まとめ：モックを理解すると開発の会話が一気にわかりやすくなる
モックとは、本物の代わりに使う仮のものです。Webデザインでは完成イメージを見せるために使い、プログラミングでは本物の処理やデータの代わりに使います。
コードにもモックはあります。テストでは、API、データベース、関数、クラスなどをモックに置き換えて、安全に動作確認をします。本物を毎回動かさずに済むので、テストが速くなり、安定し、危険な処理も避けられます。
ただし、モックは本物ではありません。便利だからといって信じすぎると、本番環境で普通に裏切られます。モックはあくまで代役です。本物に近づけて作り、必要に応じて本物との確認も行うべきです。
「モックとは？」と聞かれたら、まずはこう答えれば十分です。
モックとは、本物の代わりに使う仮のもの。
そして、コードにもモックはある。
テストや開発を安全に進めるための、かなり重要な道具である。
ここまで理解しておけば、デザインのモック、APIのモック、テストコードのモックという言葉に振り回されにくくなります。言葉に振り回される時間は、人生の中でもかなり無駄な部類です。さっさと理解して、作る側に回った方がいいです。
参考リンク：
Jest公式 Mock Functions
Python公式 unittest.mock
Mockito公式ドキュメント
Figma公式 プロトタイピングガイド
コメント