AI コーディングツールで機能を作りました。一覧もフィルターも動き、次のプロンプトで変更もできます。それでも、項目が消えた理由や小さな条件変更の影響を聞かれると、また AI に尋ねる必要があります。
小さな JavaScript フィルターで試してみましょう。残る項目を先に書き出し、在庫の条件を手で変えてから、実行結果と予測を比べます。
予測できる動作を選ぶ
「アプリ全体を教えて」は大きな課題です。カテゴリ、検索語、在庫スイッチを組み合わせたときに残る項目など、具体的な結果を選びます。
変更前に三つ考えます。
- この入力ではどの項目 ID を返すか。
- 各項目を含める・除く条件は何か。
- 在庫条件を変えても、どの結果は同じか。
構文がまだ読めなければ式を一つずつ見ます。ここで filter はコールバックが true の項目を残し、&& はすべての条件、|| はどちらか一方を要求します。紙に書いて追える大きさの入力と出力です。
フィルター学習ラボをダウンロードします。コードと 4 件のデータは教材用に作ったもので、実際の AI 回答やアプリのソースではありません。展開して filter-learning-lab を開きます。Node.js 22 以降、テキストエディター、ターミナルが必要です。依存パッケージの導入、モデル呼び出し、ネットワーク通信はありません。
実行前に三つの予測を書く
catalog.mjs と filter.mjs を読みます。カタログには次のデータがあります。
| ID | ラベル | カテゴリ | 在庫 |
|---|---|---|---|
folded-stars |
Folded stars | paper |
1 |
paper-kites |
Paper kites | paper |
3 |
clay-moons |
Clay moons | clay |
0 |
clay-bells |
Clay bells | clay |
2 |
元の在庫条件は 1 個以上です。ラベルの検索は大文字小文字を区別せず、検索語前後の空白を除きます。カテゴリ、検索、在庫のすべてが一致する必要があります。カテゴリ all はすべて、空の検索語はどのラベルにも一致します。
blank-note.md に、次の入力で期待する ID を書きます。必要に応じて関数を読みますが、観察コマンドの実行や答えを尋ねるのは後にしてください。
| ケース | カテゴリ | 検索語 | availableOnly |
説明する点 |
|---|---|---|---|---|
| A | paper |
空 | true |
在庫 1 でも含まれる理由 |
| B | all |
CLAY |
false |
在庫 0 が表示される理由 |
| C | clay |
bells |
true |
三つの条件の組み合わせ |
次に展開したフォルダーで実行します。
node observe.mjs
node --test baseline.test.mjs予測を元の結果と比較する
| ケース | 元の ID | 理由 |
|---|---|---|
| A | folded-stars, paper-kites |
どちらも paper で在庫が 1 以上 |
| B | clay-moons, clay-bells |
空白除去と大文字小文字を区別しない検索で両方一致。在庫フィルターは無効 |
| C | clay-bells |
カテゴリとラベルが一致し、在庫は 2 |
予測が違ったら、最初に誤解した条件に印を付けます。B を「在庫があるから」と説明するのは誤りです。clay-moons の在庫は 0 ですが、availableOnly が false なので除外されません。
答えを借りずに条件を説明する
完成済みメモを開いたなら閉じ、カタログを見ている人に B を説明する文章を 2〜3 文書きます。実際の入力と、在庫 0 を許す条件を含めてください。
少数のファイルと役割を区別します。
| ファイル | この演習での役割 |
|---|---|
catalog.mjs |
4 件のデータを提供 |
filter.mjs |
指定条件に一致するデータを判断 |
observe.mjs |
3 組の条件を渡し、選ばれた ID と在庫を出力 |
baseline.test.mjs |
元のフィルター動作を確認 |
観察用プログラムはターミナルの呼び出し元であり、ブラウザーの画面ではありません。実際のアプリではボタンやフォームが値を渡すかもしれません。UI が何を送るかを推測する前に、その呼び出し元を読んでください。
Yenpo のローカルコードリーダーでデータ、フィルター、呼び出し元を開いたまま読めます。ファイル検索とテキスト検索にモデル接続は不要です。自分のプロバイダーで AI Reader を使うなら、分からない条件だけを質問し、周辺のソースに戻って自分で説明を書きます。コマンドは自分で Terminal から実行し、この演習にはモデル回答は必要ありません。
条件を一つ手で変える
在庫フィルターが有効なら、二人が一つずつ使える在庫のある素材だけを表示するよう変更します。カテゴリ、検索語の正規化、スイッチ無効時の動作は変えません。
元の「1 個以上」は元の要件に対して正しいものでした。これは小さな機能変更で、隠れていた不具合の修正ではありません。
編集前に再び予測します。A から folded-stars が消えます。B はスイッチが無効なので在庫 0 を残します。C は在庫がちょうど 2 の clay-bells を残します。
新要件の確認を、元のコードに一度実行します。
node --test exercise/pair-policy.check.mjsまだ在庫 1 を許しているため、編集前には失敗する想定です。失敗したアサーションから、未実装の動作を確認します。構文エラーやファイルの欠落は別の失敗です。
filter.mjs で閾値だけを >= 1 から >= 2 に変えます。周囲の availableOnly は残し、実行します。
node observe.mjs
node --test exercise/pair-policy.check.mjs| ケース | 編集後の ID | 確認すること |
|---|---|---|
| A | paper-kites |
在庫 1 は選択した二人分の条件を満たさない |
| B | clay-moons, clay-bells |
無効時は在庫条件を迂回。検索の空白除去と大文字小文字の扱いも不変 |
| C | clay-bells |
ちょうど 2 は合格。> 2 では誤り |
元の baseline は 1 個の規則を表します。意図的な要件変更後は、該当アサーションが失敗します。新動作には別名の二人分の確認を使い、失敗を隠すためにアサーションを消さないでください。アーカイブには最初から繰り返せるよう元のソースを残しています。
変わらなかったことも含め、もう一度説明する
完成例を脇に置き、自分の言葉でメモを仕上げます。
- 元と新しい在庫閾値、変更した正確な場所。
- A だけ項目が減り、B は変わらない理由。
- C で在庫がちょうど 2 なら含める理由。
- 実行したコマンドと出力。
- 実アプリのフォーム入力、サーバー動作、永続化など、未確認のこと。
例えば「在庫フィルターが有効ならすべての条件に一致し、在庫が 2 以上必要。無効なら在庫は選択に影響しない。閾値変更で A の folded-stars が消え、B と C の ID は同じ」と具体的に説明します。この文を暗記せず、ページを閉じてコードから説明してみてください。
次は入力を変えてみましょう。実行前に結果を予測し、各項目がどの条件で残ったか、除外されたかを説明します。
自分の機能にも同じサイクルを使う
入力が見え、出力を再現できる小さな動作を選びます。ソースの版を記録し、コピーを作るか通常のバージョン管理を使い、最初の編集を狭く保ちます。実行前に予測し、違ったら次のパッチ生成を求める前に条件と呼び出し元を読みます。
場所が分からなければ不慣れなコードの入口を探すところから始めます。AI 説明の真偽を判断するなら説明を検証する演習、変更案のレビューなら具体的なパッチと失敗例を扱う Promise キャッシュの解説が役立ちます。