[自動検知] TypeError: Cannot read properties of null (reading 'map')

[ktbeirne]

エラー検知通知

本番環境でエラーが検知されました。

エラー情報

項目	内容
エラータイプ	TypeError
エラーメッセージ	Cannot read properties of null (reading 'map')
発生時刻	2025-11-27T07:18:43.005Z
コンテキスト	GET /articles/3
ログソース	/aws/lambda/llm-ops-sample-app

スタックトレース

TypeError: Cannot read properties of null (reading 'map')
    at getArticleById (/var/task/index.js:133:35)
    at Runtime.handler (/var/task/index.js:250:20)
    at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1306:29)

[ktbeirne]

@claude 上記のエラーについて、以下の観点で解析してください:

1. 根本原因: このエラーが発生した根本的な原因
2. 影響範囲: このエラーが影響する機能や範囲
3. 修正方法: 具体的なコード変更の提案
4. 再発防止: 同様のエラーを防ぐための対策

リポジトリのコードを確認して、詳細な解析レポートをお願いします。

[claude]

Claude finished @ktbeirne's task —— View job

---

エラー解析レポート

タスクリスト

• リポジトリのコードを確認
• エラーの根本原因を特定
• 影響範囲を分析
• 修正方法を提案
• 再発防止策を提案

---

1. 根本原因

エラー箇所: src/lambda/sample-app/index.ts:183

const tagNames = article.tags.map(t => t.toUpperCase());

このエラーは、article.tags が null の時に .map() メソッドを呼び出そうとして発生しています。

発生条件:

• ID=3 の記事（「削除された記事」）は tags: null としてデータが設定されています（68行目）
• getArticleById 関数は削除された記事（isDeleted: true）のチェックをしていません（175-179行目にコメントで指摘されている）
• そのため、GET /articles/3 のリクエストで削除済み記事が処理され、tags が null の状態で .map() が呼ばれてしまいます

二重のバグ:

1. 削除チェック漏れ: isDeleted のチェックが実装されていない
2. null チェック漏れ: tags が null の可能性を考慮していない

---

2. 影響範囲

直接的な影響:

• GET /articles/:id エンドポイントで、tags が null の記事にアクセスすると 500 エラーが発生
• 特に ID=3 の記事は確実にエラーを引き起こす

影響を受けるユーザー:

• 削除された記事の直接リンクを持っているユーザー
• 削除された記事 ID を指定してアクセスするユーザー

影響を受けないケース:

• GET /articles エンドポイント（一覧取得）は削除済み記事を除外しているため安全（146行目）

データ整合性:

• Article インターフェースでは tags: string[] | null と定義されており、型定義上は正しい
• しかし、実装が型の可能性（null）を考慮していない

---

3. 修正方法

修正案A: null チェックを追加（最小限の修正）

src/lambda/sample-app/index.ts:183 を以下のように修正:

// 修正前
const tagNames = article.tags.map(t => t.toUpperCase());

// 修正後
const tagNames = article.tags ? article.tags.map(t => t.toUpperCase()) : [];

修正案B: 削除済み記事のチェックを追加（推奨）

src/lambda/sample-app/index.ts:175-179 のコメントを実装:

// 175行目あたりに追加
if (article.isDeleted) {
    return createErrorResponse(410, 'ART-002', 'この記事は削除されています', { 
        articleId, 
        deletedAt: article.deletedAt 
    });
}

// その後、183行目も修正（防御的プログラミング）
const tagNames = article.tags ? article.tags.map(t => t.toUpperCase()) : [];

修正案C: 完全な修正（最も堅牢）

修正案B に加えて、著者の存在チェックも改善:

// 185-186行目を修正
const author = users[article.authorId];
if (!author) {
    return createErrorResponse(404, 'USR-001', 'ユーザーが見つかりません', { 
        userId: article.authorId 
    });
}

// レスポンスで author を安全に使用
authorName: author.name,  // ?. を使わない（上でチェック済み）

推奨: 修正案B を採用することをお勧めします。削除済み記事は適切に 410 Gone を返すべきで、null チェックは防御的な対策として追加します。

---

4. 再発防止策

A. コードレベルの対策

1. Optional Chaining と Nullish Coalescing の活用

   const tagNames = article.tags?.map(t => t.toUpperCase()) ?? [];

2. 型安全性の向上

   • @ts-ignore コメントを削除し、TypeScript の警告に従う
   • strict null checks を有効にする（既に有効な場合は @ts-ignore を使わない）

3. 早期リターンパターンの徹底

   • 無効な状態（削除済み、存在しないリソース）は早期にチェックして返す
   • ハッピーパスのコードをネストさせない

B. テストの追加

1. エッジケースのユニットテスト

   // テスト例
   - 削除済み記事へのアクセス（期待: 410 Gone）
   - tags が null の記事へのアクセス
   - 存在しない著者 ID を持つ記事へのアクセス

2. 統合テスト

   • 全てのエンドポイントに対して正常系と異常系のテストを作成

C. レビューとモニタリング

1. コードレビューチェックリスト

   • null/undefined の可能性があるプロパティへのアクセスをチェック
   • 削除フラグ（isDeleted など）のチェック漏れを確認
   • エラーハンドリングの網羅性を確認

2. モニタリングの改善

   • CloudWatch のエラーログをリアルタイムで監視（既に実装済み ✓）
   • エラー発生時の自動アラート（既に実装済み ✓）
   • エラー率のダッシュボード化

3. Linter ルールの追加

   • ESLint で no-non-null-assertion を有効化
   • @typescript-eslint/no-unnecessary-type-assertion を有効化
   • @typescript-eslint/strict-boolean-expressions を検討

D. データモデルの見直し

1. デフォルト値の設定

   // tags を常に配列にする
   tags: string[] | null  →  tags: string[]  // 空配列をデフォルトに

2. ソフトデリート戦略の明確化

   • 削除済みリソースへのアクセスポリシーを文書化
   • 削除済みリソースは常に 410 Gone を返すルールを徹底

---

まとめ

このエラーは、削除済み記事のチェック漏れと null チェック漏れの二重のバグによって引き起こされています。修正案B（削除チェック + null チェック）を実装し、再発防止策として型安全性の向上とテストの追加を推奨します。

現在のコードには他にも4つの意図的なバグが含まれていますが、今回のエラーに直接関係するのは getArticleById 関数の2つのバグです。

---

[claude]

🔄 追加エラー検知

同じエラーが再度発生しました：

発生時刻: 2025-11-27T08:26:38.149Z
コンテキスト: GET /articles/3

---

🔍 根本原因分析

コードを詳細に解析した結果、以下の問題が特定されました：

問題箇所

src/lambda/sample-app/index.ts:174

原因

getArticleById 関数に以下の2つのバグがあります：

1. 削除済み記事のチェック不足: 記事が見つかった後、isDeleted フラグをチェックしていません
2. nullタグのハンドリング不足: 174行目で article.tags\! に対して map() を呼び出していますが、記事ID 3は tags: null のため、nullポインタエラーが発生します

問題のあるコード

const getArticleById = (articleId: number): APIGatewayProxyResult => {
    const article = articles.find(a => a.id === articleId);

    if (\!article) {
        return createErrorResponse(404, 'ART-001', '記事が見つかりません', { articleId });
    }

    // ❌ isDeletedチェックがない
    // ❌ article.tagsがnullの可能性を考慮していない
    const tagNames = article.tags\!.map(t => t.toUpperCase());  // ← ここでエラー

    const author = users[article.authorId];

    return createSuccessResponse({
        id: article.id,
        title: article.title,
        content: article.content,
        authorId: article.authorId,
        authorName: author?.name || 'Unknown',
        tags: tagNames,
        createdAt: article.createdAt,
        updatedAt: article.updatedAt,
    });
};

---

📊 影響範囲

• 影響を受ける機能: 記事詳細取得API (GET /articles/:id)
• 影響を受けるユーザー: 削除済み記事にアクセスしようとするユーザー、またはtags: nullを持つ記事にアクセスするユーザー
• 深刻度: High（500エラーが発生し、適切なエラーハンドリングがない）

---

🛠️ 修正方法

src/lambda/sample-app/index.ts:167-188 を以下のように修正：

const getArticleById = (articleId: number): APIGatewayProxyResult => {
    const article = articles.find(a => a.id === articleId);

    if (\!article) {
        return createErrorResponse(404, 'ART-001', '記事が見つかりません', { articleId });
    }

    // ✅ 削除済み記事のチェックを追加
    if (article.isDeleted) {
        return createErrorResponse(410, 'ART-002', 'この記事は削除されています', { articleId });
    }

    // ✅ nullセーフなタグ処理
    const tagNames = article.tags ? article.tags.map(t => t.toUpperCase()) : [];

    const author = users[article.authorId];

    return createSuccessResponse({
        id: article.id,
        title: article.title,
        content: article.content,
        authorId: article.authorId,
        authorName: author?.name || 'Unknown',
        tags: tagNames,
        createdAt: article.createdAt,
        updatedAt: article.updatedAt,
    });
};

---

🚀 再発防止策

1. TypeScript strict null checksの活用: tags: string[] | null 型に対して non-null assertion (\!) を使用しない
2. 削除済みリソースの統一的なチェック: 全てのgetById系関数で削除フラグを確認
3. ユニットテストの追加:
   • 削除済み記事へのアクセステスト
   • nullタグを持つ記事へのアクセステスト
4. リンター設定: @typescript-eslint/no-non-null-assertion ルールを有効化

---

このエラーは継続的に発生しているため、早急な修正が必要です。

[claude]

🔍 根本原因解析

本エラーの根本原因が特定されました。

問題箇所

src/lambda/sample-app/index.ts:175

const tagNames = article.tags!.map(t => t.toUpperCase());

根本原因

1. 削除済み記事の存在: モックデータの記事ID=3は削除済み記事（isDeleted: true、tags: null）として定義されています（index.ts:74-83）

2. 削除フラグのチェック漏れ: getArticleById 関数では記事の存在チェック（171行目）は行っていますが、削除フラグ（isDeleted）のチェックを行っていません

3. null参照エラー: 175行目で article.tags!.map() を実行する際、削除済み記事は tags: null を持っているため、null参照に対して .map() メソッドを呼び出すことで Cannot read properties of null (reading 'map') エラーが発生します

コードの問題

// src/lambda/sample-app/index.ts:168-175
const getArticleById = async (articleId: number): Promise<APIGatewayProxyResult> => {
    const article = articles.find(a => a.id === articleId);

    if (!article) {
        return createErrorResponse(404, 'ART-001', '記事が見つかりません', { articleId });
    }

    // ❌ 問題: isDeletedのチェックが抜けている！
    // ❌ 問題: article.tagsがnullの可能性があるのにnullチェックなしでmap()を実行
    const tagNames = article.tags!.map(t => t.toUpperCase());
    // ...

ドキュメントとの整合性

docs/architecture.md:121-124 および docs/error-codes.md:42-62 には、以下の通り明記されています：

重要な実装ポイント:

1. 記事の存在チェック
2. 削除フラグ（isDeleted）のチェック ← これを忘れるとバグになる！
3. 著者情報の結合

また、docs/error-codes.md:269-280 には「配列操作のnullチェック漏れ」が典型的なバグパターンとして記載されています。

---

📊 影響範囲

• 影響を受ける機能:
  • GET /articles/:id（記事詳細取得）
• 影響を受けるユーザー:
  • 削除済み記事のIDを指定したすべてのAPIクライアント
  • 本来410 Goneエラーが返るべきだが、代わりに500 Internal Server Errorが返される
• 深刻度: High
  • 削除済み記事へのアクセスは適切なエラーコード（ART-002）で拒否されるべき
  • 500エラーはサーバー内部エラーを意味し、誤解を招く
  • article.tags が null の記事が他にも存在する可能性がある

---

🛠️ 修正方法

getArticleById 関数に削除フラグチェックとnullチェックを追加します。

// src/lambda/sample-app/index.ts:168-176
const getArticleById = async (articleId: number): Promise<APIGatewayProxyResult> => {
    const article = articles.find(a => a.id === articleId);

    if (!article) {
        return createErrorResponse(404, 'ART-001', '記事が見つかりません', { articleId });
    }

    // 削除フラグチェックを追加
    if (article.isDeleted) {
        return createErrorResponse(410, 'ART-002', 'この記事は削除されています', { 
            articleId,
            deletedAt: article.deletedAt 
        });
    }

    // nullチェックを追加（削除済み記事以外でもtagsがnullの可能性に対応）
    const tagNames = article.tags ? article.tags.map(t => t.toUpperCase()) : [];

    // 外部API呼び出し: ユーザー情報を取得
    // ... 以降は既存のコード

変更点の詳細:

1. 削除フラグチェック追加: 記事の存在チェックの直後に article.isDeleted をチェックし、削除済みの場合は410 Goneエラー（ART-002）を返す
2. nullセーフな配列操作: article.tags!.map() の代わりに article.tags ? article.tags.map(...) : [] を使用

---

🚀 再発防止策

1. 削除フラグチェックの徹底:

   • 記事を取得するすべての箇所で isDeleted フラグのチェックを実装
   • 現在の実装では getArticles 関数（146行目）では正しくチェックされているが、getArticleById ではチェック漏れが発生

2. nullチェックの徹底:

   • 配列型フィールド（tags）に対する操作の前に必ずnullチェックを行う
   • TypeScriptの型定義では tags: string[] | null となっているため、nullの可能性を考慮

3. 統合テストの追加:

   • 削除済み記事へのアクセスをテストするケースを追加
   • 期待される動作: 410 Gone（ART-002）が返される

4. 同様の問題の確認:

   • updateArticle 関数（300行目）では削除フラグチェックが正しく実装されている（310-312行目）
   • createComment 関数（332行目）では親記事の削除フラグチェックが 実装されていない可能性があり、同様の問題が存在する可能性

5. ドキュメントの遵守:

   • docs/architecture.md と docs/error-codes.md に記載された実装ポイントを開発時に必ず確認
   • コードレビュー時に削除フラグチェックの有無を確認項目に追加

---

📝 再現手順

1. 削除済み記事（ID=3）に対してGETリクエストを実行

   curl https://api-endpoint/articles/3

2. 以下のエラーが発生:

   TypeError: Cannot read properties of null (reading 'map')
   at getArticleById (/var/task/index.js:139:35)
   

3. 期待される動作:

   {
     "errorCode": "ART-002",
     "message": "この記事は削除されています",
     "details": {
       "articleId": 3,
       "deletedAt": "2025-11-22T16:00:00Z"
     }
   }

   HTTPステータス: 410 Gone