AIでも壊れない堅牢コードへ鍛え直す！
コードレビュー道場 #3：非機能要件

公開日：2025年12月13日

最終更新日：2026年02月22日

このページでは、AIが見落としやすい非機能要件（性能・信頼性・保守性など）の観点で、実際のコード断片を読むコードレビュー形式の4択クイズを体験します。「動く」だけでは守れない、本番で踏ん張る品質を鍛えるのが狙いです。

4択クイズ（10問・全問解説付き）で腕試し → 解説でなぜ落ちるのか／なぜ運用がつらいのかを言語化。「読む→解く→わかる」で、AI生成コードをプロ品質へ引き上げる現場の勘所を身につけていきましょう。

今すぐクイズに挑戦
（10問・約3分・解説つき）

プリンシプルオブプログラミング
AI時代を生き抜く「101の設計原則」

#3 非機能要件：落ちるコードを鍛え直せ！目次

クイズに挑戦する(10問)

参考文献・出典
このページの著者
シェア

コードレビュー道場 #3～落ちるコードを非機能要件で鍛え直せ！～

1. 次のコードは、画面を破棄したあともイベントリスナーが残り続け、メモリリークやハンドラの二重実行を引き起こす可能性があります。安定性・保守性の観点から、もっともよい改善はどれでしょうか？


function attach() {
  const btn = document.getElementById('save');
  btn.addEventListener('click', () => {
    save();
  });
}

A. コールバックを無名関数ではなく名前付き関数にしておく
B. addEventListener のオプションに { passive: true } を追加する
C. コンポーネントのライフサイクルに合わせて removeEventListener する、または1度きりのリスナーにするなど、クリーンアップの仕組みを組み込む
D. save 関数の中で現在のクリック回数をログに残す

2. 次のコードは、ダッシュボード表示のたびに重い集計処理を実行しています。性能とスケーラビリティの観点から、もっとも有効な改善はどれでしょうか？


function renderDashboard(userId) {
  const stats = calculateAllStats(userId); // 重い処理
  return buildHtml(stats);
}

A. calculateAllStats の中でログを出し、どこが遅いか把握できるようにする
B. buildHtml の処理を最適化し、テンプレートエンジンを高速なものに変える
C. 一定期間ごとに集計結果をバッチ処理で更新してキャッシュし、画面表示時にはキャッシュ済みデータを参照する
D. ダッシュボードの表示頻度を制限する

3. 次のコードは、外部APIがハングした場合でもいつまでも待ち続けてしまい、スレッドや接続を長時間専有してしまう可能性があります。非機能要件（応答性・信頼性）の観点から、もっとも優先して行うべき改善はどれでしょうか？


async function fetchProfile(userId) {
  const res = await fetch(`https://api.example.com/users/${userId}`);
  if (!res.ok) {
    throw new Error('failed');
  }
  return res.json();
}

A. API呼び出しの前後でログを詳細に出力し、失敗時に原因を追いやすくする
B. エラーメッセージを状況に応じて分かりやすく書き分ける
C. タイムアウトと上限付きリトライを導入し、一定時間で処理を打ち切って呼び出し元に制御を戻す
D. 同時に呼び出せる fetchProfile の数を制限するキューを用意する

4. 次のコードは、機能フラグを毎回リモートから取得しており、外部サービス障害時にアプリ全体が影響を受けやすくなっています。信頼性と性能の観点から、もっとも適切な改善はどれでしょうか？


async function getFeatureFlags() {
  const res = await fetch('https://flags.example.com/config.json');
  return res.json();
}

A. フラグの取得に失敗した場合は、常にすべての機能を無効にする
B. 結果を常に localStorage に保存しておき、次回起動時にだけそこから読む
C. 一定間隔または起動時にフラグを取得してキャッシュし、通常の処理ではキャッシュ済み値を参照するようにする
D. 外部サービスのレスポンス時間をログに出し、遅い場合はアラートを上げる

5. 次のコードは、内部エラーも「404 Not Found」として返しており、運用時に原因の特定が困難です。運用性と信頼性の観点から、もっともよい改善はどれでしょうか？


async function handler(req, res) {
  try {
    const data = await loadFromDb();
    res.end(JSON.stringify(data));
  } catch (e) {
    res.statusCode = 404;
    res.end('Not found');
  }
}

A. すべてのエラーを 500 に統一し、「Internal Server Error」を返す
B. 例外内容やコンテキストをログに残しつつ、内部エラーと本当の404を区別して適切なステータスコードを返す
C. エラー発生時には何も返さず接続を切る
D. loadFromDb の中で例外を握りつぶし、この handler では正常系だけ扱う

6. 次のコードは、外部サービスが落ちているときでも延々とリトライを続けてしまいます。システム全体の安定性を高めるために、もっとも重要な改善はどれでしょうか？


async function sendNotification(payload) {
  while (true) {
    try {
      await fetch('https://api.example.com/notify', {
        method: 'POST',
        body: JSON.stringify(payload)
      });
      return;
    } catch (e) {
      // 失敗したらリトライ
    }
  }
}

A. リトライの間隔を一定時間スリープするようにし、連打しないようにする
B. 失敗したときはログだけ残し、リトライは行わないようにする
C. 最大リトライ回数やサーキットブレーカー、バックオフなどを導入し、障害時の粘り方とあきらめ方を設計する
D. fetch の URL を環境変数から受け取るようにする

7. 次のコードは、大量のアイテムを描画するときにブラウザが固まりやすくなります。性能とユーザビリティの観点から、もっとも効果が大きい改善はどれでしょうか？


function renderList(items) {
  const container = document.getElementById('list');
  container.innerHTML = '';
  items.forEach(item => {
    const li = document.createElement('li');
    li.textContent = item.name;
    container.appendChild(li);
  });
}

A. forEach ではなく for ループで回すように書き換える
B. DOMノードを DocumentFragment や文字列バッファでまとめて構築し、最後に一括で追加する
C. items の length をログに出力し、大きい場合は警告する
D. li 要素の textContent を innerHTML に変える

8. 次のコードは、重い処理のたびに詳細なログを出しており、高負荷時にログI/O自体がボトルネックになる恐れがあります。性能と運用性のバランスをとるために、もっとも適切な改善はどれでしょうか？


function processItem(item) {
  console.log('START PROCESS', item);
  doHeavyWork(item);
  console.log('END PROCESS', item);
}

A. ログに出す項目を減らし、メッセージを短くする
B. ログ出力を非同期にし、処理本体とは別スレッドで書き込む
C. ログレベル・サンプリング・環境設定などを導入し、通常運用では出力量を抑えつつ、必要なときだけ詳細ログを出せるようにする
D. doHeavyWork の前後で process.hrtime を使って正確な時間を計測する

9. 次のコードは、エラーを握りつぶしてしまい、問題の検知や復旧が困難になります。非機能要件（信頼性・保守性）の観点から、もっとも望ましいエラーハンドリングはどれでしょうか？


async function saveUser(user, db) {
  try {
    await db.insert('users', user);
  } catch (e) {
    // なにもしない
  }
}

A. 例外が発生したときは false を返し、呼び出し側で気づいてもらうだけにする
B. 例外の種類に応じてログを記録し、必要に応じて上位に投げ直すか失敗を表す値を返す
C. 例外が発生した場合は alert でユーザーに通知する
D. 例外を文字列に変換してから無視する

10. 次のコードは、典型的なN+1クエリ問題を抱えています。性能とスケーラビリティの観点から、もっともインパクトの大きい改善はどれでしょうか？


async function listOrdersWithUser(db) {
  const orders = await db.query('SELECT * FROM orders');
  for (const order of orders) {
    const rows = await db.query(
      'SELECT * FROM users WHERE id = ?',
      [order.user_id]
    );
    order.user = rows[0] ?? null;
  }
  return orders;
}