カテゴリE最終回——道具は揃った
カテゴリEもいよいよ最終回です。E-01からE-09まで、入力から出力、変数、式、条件分岐、繰り返し、関数、配列、オブジェクトと、コードを読むための道具を一つずつ揃えてきました。道具は出揃いました。最後に扱うのは、同じ結果を出す手順は一つではなく、そのなかには賢いものとそうでないものがある、という視点です。
このスライドのポイント
- E-01からE-09までで、入力・処理・出力、変数、式、条件分岐、繰り返し、関数、配列、オブジェクトを学んだ
- コードを読むための道具は出揃った
- 最終回のテーマ: 同じ結果を出す手順は一つではなく、そのなかに賢い手順とそうでない手順がある
アルゴリズムと計算量の定義
アルゴリズムとは、問題を解くための処理手順のことです。計算量とは、データの量が増えたときに、時間やメモリがどれくらい増えるかの目安を指します。たとえば、全件を一回ずつ見る手順なら、増える時間は件数に比例します。いっぽう、全部の組み合わせを見る手順なら、件数の二乗のペースで増えていきます。同じ答えにたどり着くとしても、この増え方の違いが、後で大きな差になります。
このスライドのポイント
- アルゴリズム＝問題を解くための処理手順
- 計算量＝データ量が増えたとき、時間やメモリがどれくらい増えるかの目安
- 全件を1回ずつ見るなら件数に比例して増える
- 全組み合わせを見るなら件数の2乗で増える
なぜこの視点が必要か
この視点がないと、テストデータでは動いたのに本番の一万件で固まってしまう、という失敗の原因が読めません。少ない件数では、どんな手順でも一瞬で終わるため、差が見えないのです。これは、B-06で見たローカルと本番の違いの、データ量版だと考えてください。手元で速いことは、本番で速いことを保証しません。だからこそ、増えたときにどうなるかを、あらかじめ問う必要があります。
このスライドのポイント
- この視点がないと「テストデータでは動いたのに本番の1万件で固まる」の原因が読めない
- 少件数ではどの手順でも一瞬で終わり、差が見えない
- B-06で見たローカルと本番の差の、データ量版
- 手元で速いことは本番で速いことを保証しない
件数と時間のグラフで捉える
全体像を、件数と時間のグラフで思い描いてみましょう。横軸がデータの件数、縦軸が処理にかかる時間です。件数に比例する手順は、まっすぐな直線を描いて緩やかに伸びます。件数の二乗で増える手順は、最初はほとんど同じでも、途中から急なカーブを描いて跳ね上がります。少ない件数では二本の線はほぼ重なって見え、大量になったときに初めて差が爆発する、という形を覚えてください。
このスライドのポイント
- 横軸＝データの件数、縦軸＝処理にかかる時間
- 件数に比例する手順は、まっすぐな直線で緩やかに伸びる
- 件数の2乗で増える手順は、途中から急なカーブで跳ね上がる
- 少件数では2本の線はほぼ重なる／大量で初めて差が爆発する
名簿から重複を探す例
具体例で考えます。名簿のなかから重複している人を探す場面です。素直なやり方は、一人ずつ全員と見比べる手順で、これは組み合わせの数だけ手間がかかるため、件数の二乗で増えます。もう一つは、いったん名前を並べ替えてから隣どうしを見ていく手順で、こちらはずっと緩やかにしか増えません。百人ならどちらも一瞬ですが、一万人になると差は歴然です。どの手順を選ぶか、それがアルゴリズムを選ぶということです。
このスライドのポイント
- 例: 名簿のなかから重複している人を探す
- 手順A: 一人ずつ全員と見比べる → 組み合わせの数だけかかり、件数の2乗で増える
- 手順B: いったん並べ替えてから隣どうしを見る → ずっと緩やかにしか増えない
- 100人ならどちらも一瞬／1万人では差が歴然
- 手順の選び方＝アルゴリズムを選ぶこと
技術サンプル: データ量と速さの表
サンプルは、種別が図解、目的はデータ量と手順による速さの違いを一目で捉えることです。表を見てください。手順Aは件数に比例し、手順Bは件数の二乗で増えます。読み方の要点は二つです。まず、テスト時に速いからといって本番でも速いとは限らないこと。そして、その場の速さより増え方の性質が大事だということです。AIにコードを作らせたときは、この処理はデータが一万件になっても実用的な速さですか、遅くなるならどの部分ですか、と聞いてみてください。
このスライドのポイント
- 種別: diagram
- 目的: データ量と手順による速さの違いを一目で捉える
- サンプル本体:
「いま速い」と「増えても速い」
混同しやすいのが、いま速いことと、増えても速いことの違いです。少ない件数での速さは、計算量の良さを何も保証しません。二乗で増える手順でも、百件ならまったく問題なく動いてしまいます。だからこそ、動いた事実だけで安心せず、想定する件数まで増やしたときにどうなるかを、別に確かめる必要があります。
このスライドのポイント
- 混同しやすい: 「いま速い」vs「増えても速い」
- 少件数での速さは、計算量の良さを保証しない
- 2乗で増える手順でも、100件ならまったく問題なく動いてしまう
- 動いた事実だけで安心しない
バイブコーディングでの確認点
バイブコーディングでの確認点です。一覧の表示、検索、集計といった処理をAIに作らせたら、想定件数は何件です、この規模で問題ない書き方ですか、と件数を具体的に渡して確認する習慣をつけてください。これは、A-07で学んだ制約を渡すことの実践でもあります。件数という制約を伝えるだけで、AIはより現実に即した手順を選びやすくなります。
このスライドのポイント
- 一覧・検索・集計をAIに作らせたら「想定件数は◯件です。この規模で問題ない書き方ですか」と件数を渡して確認
- 件数という制約を渡すのは、A-07で学んだ「制約を渡す」ことの実践
- 件数を伝えるだけで、AIは現実に即した手順を選びやすくなる
まとめとカテゴリE修了
最後に一問一答です。テストでは速かった処理が、本番で遅くなる典型的な原因は何でしょうか。……答えは、データ量の増加です。計算量の増え方が急な手順だったために、件数が増えて遅くなったのです。三十秒のまとめです。同じ結果でも手順で速さは変わり、その差はデータが増えたときに現れます。件数を渡して確認する癖をつけてください。これでカテゴリEは修了、コードを読むための道具が揃いました。次回からはカテゴリF、JavaScriptそのものと実行環境の話に進みます。関連資料は「AI Builder 技術ロードマップ」「リファクタリング指示文50」です。
このスライドのポイント
- 一問一答: テストで速かった処理が本番で遅くなる典型原因は？ → データ量の増加（計算量の増え方が急な手順だった）
- 30秒まとめ: 同じ結果でも手順で速さは変わり、差はデータが増えたときに現れる／件数を渡して確認する
- カテゴリE修了、コードを「読む」道具が揃った
- 次回: カテゴリF、JavaScriptそのものと実行環境へ
- 関連資料: 「AI Builder 技術ロードマップ」「リファクタリング指示文50」
