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. 次のコードは、すべてのジョブが毎分ぴったりのタイミングで重い処理を走らせる設計になっています。他のサービスも同じタイミングで動くと、一時的な負荷スパイクを招く可能性があります。非機能要件（安定性・スループット）の観点から、もっともよい改善はどれでしょうか？


// 毎分0秒に実行される
setInterval(runJob, 60 * 1000);

function runJob() {
  // 重い集計処理
}

A. 実行間隔を短くし、1回あたりの仕事量を小さくする
B. runJob の処理を別スレッドに移し、メインスレッドを空けておく
C. 実行タイミングにランダムなジッタを持たせるか、ジョブ管理基盤側で実行タイミングを分散させる
D. runJob の前後でログを出しておき、後からピークを分析できるようにする

3. 次のコードでは、ログを永続化せずメモリ上の配列に貯め続けています。長時間稼働時の安定性を高めるために、もっとも重要な改善はどれでしょうか？


const logs = [];

function logEvent(event) {
  logs.push({
    at: new Date().toISOString(),
    event
  });
}

A. ログのタイムスタンプを UNIX時間にする
B. logs をオブジェクトではなく Map に変更する
C. 保持件数に上限を設け、超えた分を外部に吐き出すか破棄する仕組みを入れて、メモリ使用量を制御する
D. logEvent 内でログ件数を監視し、一定件数ごとに警告ログを出す

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


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

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

5. 次のコードは、ユーザー入力に対するバリデーションがなく、異常値で例外や異常動作を起こしやすくなっています。信頼性の観点から、もっとも重要な改善はどれでしょうか？


function calculate(pageSize) {
  return 1000 / pageSize;
}

A. 計算結果を Math.floor で丸める
B. pageSize が 0 や負の値、極端に大きい値などの場合はエラーとして扱い、安全な経路で呼び出し元に伝える
C. 1000 という値を定数に切り出す
D. 計算結果が Infinity や NaN のときだけログに出す

6. 次のコードは、外部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 の数を制限するキューを用意する

7. 次のコードは、典型的な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;
}

A. ループの中で await せず、Promise.all でまとめて待つようにする
B. users の取得を別の関数に切り出して可読性を上げる
C. JOIN や IN 句などを使って、必要なユーザー情報をまとめて取得するクエリに書き換える
D. クエリの実行時間をログ出力し、遅い場合にアラートを上げる

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 transfer(db, fromId, toId, amount) {
  await db.execute(
    'UPDATE accounts SET balance = balance - ? WHERE id = ?',
    [amount, fromId]
  );
  await db.execute(
    'UPDATE accounts SET balance = balance + ? WHERE id = ?',
    [amount, toId]
  );
}

A. ログに送金の開始と終了を必ず記録する
B. fromId と toId が同じ場合は何もしないようにする
C. 2つの更新を1つのトランザクションで実行し、途中で失敗した場合にはロールバックされるようにする
D. UPDATE 文の前に、残高がマイナスにならないことをチェックする

10. 次のコードは、リトライ戦略が単純で、ネットワークが一時的に不安定な場合と恒久的に落ちている場合を区別していません。非機能要件（信頼性）の観点から、より良い改善はどれでしょうか？


async function fetchWithRetry(url) {
  for (let i = 0; i < 2; i++) {
    try {
      const res = await fetch(url);
      if (!res.ok) throw new Error('bad status');
      return res;
    } catch (e) {
      await new Promise(r => setTimeout(r, 100));
    }
  }
  throw new Error('failed after 2 retries');
}

A. リトライ回数を大幅に増やして、諦めるまで長く粘るようにする
B. エラーの種類（タイムアウト・一時的エラー・4xxなど）に応じてリトライ可否と回数・間隔を変える
C. エラー時には常に同じステータスコードを返すようにする
D. リトライのたびにログを出しておき、後から原因を分析しやすくする

次のクイズ(#1 DRY/KISS：AIコードをリファクタせよ！)へ

今すぐクイズに挑戦プログラミングクイズ一覧へ

参考文献・出典

プリンシプルオブプログラミング～3年目までに身につけたい一生役立つ101の原理原則～
上田勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3

※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。

このページの著者

もちもちみかん（システムエンジニア）

社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。

経験：Webアプリ／業務システム

得意：PHP・JavaScript・MySQL・CSS

個人実績：フォーム生成基盤／クイズ学習プラットフォーム等

詳しいプロフィールはこちら！　　もちもちみかんのプロフィール

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

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

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

落ちるコードを非機能要件で鍛え直せ！
採点結果

参考文献・出典

このページの著者

もちもちみかん.comとは

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

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

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

参考文献・出典

このページの著者

シェアしてね

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

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