【Flutter】 APIエラーを定義するクラスはJSONそのままで保持すると拡張性が上がる

@Freezed(toJson: false)
abstract class ApiError with _$ApiError {
const factory ApiError({
required String code,
required String message,
@JsonKey(readValue: _readExtraJson) Map<String, dynamic>? extra,
}) = _ApiError;
 
const ApiError._();
 
factory ApiError.fromJson(Map<String, dynamic> json) =>
_$ApiErrorFromJson(json);

/// カスタム `toJson` の実装（元のJSONの形に復元）
Map<String, dynamic> toJson() {
return {
'code': code,
'message': message,
if (extra != null) ...extra!,
};
}
}

/// `extra` に元のJSONマップ全体を取り込むための readValue
Object? _readExtraJson(Map<dynamic, dynamic> json, String key) {
final extra = Map<String, dynamic>.from(json)
..remove('code')
..remove('message');
return extra.isEmpty ? null : extra;
}

無意識の補完を抑制しよう

 

■ 問題

仕事や勉強をしていると、内容を無意識のうちに補完してしまうことがあります。

よくある例：
  • 仕様書を読んで曖昧な部分を確認せず、決めつけて実装を始める
  • 説明を聞いて「前にやったやつと同じだろう」と思い込む
  • エラーが出たときに「多分ここが原因だろう」と決め打ちで修正する

実際には細かい仕様や前提を理解していないのに、 「分かった気」になって進めてしまう状態です。

■ なぜ起こるのか

  • 過去の経験をもとにパターンへ当てはめてしまう
  • 曖昧な情報をそれっぽく解釈してしまう
  • 疑問を持つ前に手が動いてしまう（思考のショートカット）
これは能力が低いからではなく、処理効率が高い人ほど起きやすい現象です。

■ 対策

1. トリガーを作る（if-thenプランニング）

無意識を止めるための条件を決めます。

  • 「多分」「おそらく」と思ったとき
  • 仕様書やドキュメントを読み終えたとき
  • 実装を始める直前

→ このタイミングで「本当に理解しているか？」と確認する

2. 分解して曖昧さを潰す

タスクを具体レベルまで分解します。

「ユーザー一覧APIを作る」
↓
・エンドポイントは？（/users？ /api/users？）
・GET？POST？
・認証は必要？
・ページネーションある？
・返す項目は？（id, nameだけ？ emailも？）
↓
・レスポンス形式は？（JSON構造）
・エラー時の仕様は？
↓
・DB設計はどうなっている？
・既存APIとの違いは？

掘り下げると「あれ？」と思うポイントが出てきます。 そこが“わかっていない部分”です。

3. 説明できるまで理解する

「他人に説明できるか？」で理解度を測ります。

  • 説明中に詰まる＝理解不足
  • 記事やメモとしてアウトプットすると効果的

4. 逆質問する（能動的に疑う）

  • この仕様、本当にこれでいい？
  • 別の解釈はない？
  • このケースはどうなる？

受け身だと補完が働くため、意識的に疑うことが重要です。

5. 仮説と事実を分離する

  • 事実：ドキュメントに書いてある内容
  • 仮説：「こういうはず」という自分の考え

仮説を切り分けることで、確認すべきポイントが明確になります。

■ まとめ

  • 無意識の補完は誰にでも起きる
  • 重要なのは「気づく仕組み」を作ること
  • 分解・言語化で「わからない」を見つける

2026/07/14

  • CognitoでWAFを設定し、メンテナンス中はメンテナンス画面を出す検証を行ったが、以下の場合はうまく機能しなかった
    • ログイン画面を表示
    • メンテナンスに切り替え
    • ログインボタン押下
    • Access deniedというエラーになり、設定したカスタムレスポンスが返ってこない
  • 回避方法として、レスポンスコードを302にし、ヘッダにLocation: リダイレクト先URLと設定し、リダイレクト先をメンテナンスのページにするという方法がある