学習ページを開くと、ここに進捗が保存されます。
まだ学習履歴はありません。
つくることで、考える力が育ち、
日常が少しずつ面白くなっていく。
この場所は、そんな変化を応援する
プログラミング学習サイトです。
つくる人が、
やさしい未来を
つくっていく。
コードで広がる
やさしい社会を、
一緒につくろう。
サイトを作っていたら、いつの間にか海外からアクセスが——。HTMLだけ先に海外進出。
続きを読む →プログラミングを学ぶことは、世界の見え方を少しずつ変えていくこと。
この場所が、みなさんの「つくってみたい」を後押しできますように。
コードを書けば、
きっと、見える世界が変わる。
つくることで、考える力が育ち、
日常が少しずつ面白くなっていく。
この場所は、そんな変化を応援する
プログラミング学習サイトです。
プログラミングの楽しさを、最初の一歩から。環境構築〜「Hello, World!」までやさしく解説します。
2026.09.13
3分でチェック！
理解度を試して、次のステップへ。
完了した記事 18 / 28
ミニテスト正解率 76%
学習継続日数 12日
プログラミングを学ぶことは、世界の見え方を少しずつ変えていくこと。この場所が、みなさんの「つくってみたい」を後押しできますように。
つくる人が、
やさしい未来をつくっていく。
KAZU × AI / 30日公開チャレンジ
実際にコードを書き、失敗し、直しながら、自分の作品を完成させる初心者向け学習サイトです。
ひとつ動いた。その喜びから、次の一歩へ。
第1回「職場に、ものすごく速い新人が来た」
助手のJavaScriptくんと、指示・画面の役割・条件分岐を学ぶ物語。全3ページ。
掲載日：2026年9月12日
完成度42％｜第1段階終盤 → 第2段階入口
① ホームページ → ② 計算アプリ → ③ 便利ツール → ④ オリジナル作品
ホームページを一軒の家から始め、記事・作品・画廊・交流広場へ少しずつ増やしていく構想を「年間計画」に整理しました。
2026年9月19日更新・v2.18：内部構造を整理。ページ本体から参照されていなかった重複JavaScriptファイルを削除し、現在の表示・教材・学習進捗機能はそのまま維持しました。
2026年9月19日更新・v2.15：ログイン不要の「学習の続き」を追加。閲覧した学習ページ、進捗率、前回の続き先をブラウザ内に保存し、ホームから再開できるようにしました。メールアドレスやパスワードは収集しません。
2026年9月18日更新・v2.12：アクセスログ用Worker設定を追加。講義ナビゲーションを再点検。JavaScript第1回1ページ目→2→3→第2回以降へ連続移動できる構成を確認し、存在しないページ指定時に画面が空になる問題も防止しました。再読み込み時はホームへ戻ります。
2026年9月14日更新・v1.08：PC版トップ画像の位置を修正。街並みと塔を左へ寄せ、見本画像に近い中央配置へ調整しました。iPhone版は変更していません。
2026年9月14日更新・v1.07：PC版の崩れを修正。右上の英字重なり・装飾の崩れ・下部の大きな空白を解消し、ヒーロー画像と3カラムを安定した配置に調整。ピンクも濃いまま維持。
2026年9月14日更新・v1.06：PC版のピンクを強化。見出し・ボタン・アクセント・進捗リングを濃いローズ〜マゼンタ寄りに変更。iPhone版は従来表示のまま維持。
2026年9月14日更新・v1.05：PC版ホームをさらに作り直し。上部ヘッダーの重複をなくし、見本の「左に大きな見出し・右に街並み・下に3カラム」の構成へ近づけました。iPhone版はそのままです。
2026年9月13日更新・v1.02：トップ画像を背景表示から画像パネル表示へ変更し、絵全体が見えるように修正しました。
2026年9月13日更新・v1.01：トップページを高級感のある黒・アイボリー・くすみローズ中心のエディトリアルデザインへ変更。第三者ブランドのロゴやマークは使用していません。
2026年9月13日更新・v1.00：並び替え操作をパソコン・iPhone共通仕様に変更。マウスクリック、タッチ操作、キーボード操作で記事一覧と編集後記の「新しい順／番号順（昇順）」を切り替えられるようにしました。
2026年9月13日更新・v0.99：並び替え機能を修正。記事と編集後記の回番号を見出しから直接読み取り、「新しい順」と「番号順（昇順）」を切り替える方式に変更しました。
2026年9月13日更新・v0.98：編集後記一覧にも並び替えボタンを追加。「新しい順」と「番号順（昇順）」を切り替えられるようにしました。
2026年9月13日更新・v0.97：記事一覧右上に並び替えボタンを追加。「新しい順」と「番号順（昇順）」を切り替えられるようにしました。
2026年9月13日更新・v0.96：記事一覧の表示順を変更。新しい記事を上、古い記事を下に並べる方式にしました。
2026年9月13日更新・v0.95：記事の続きとして、第6回 TypeScript、第7回 Java、第8回 C# の3話を追加。それぞれの言語の性格と得意分野を、プログラム村の職人たちの物語として紹介しました。
2026年9月13日更新・v0.94：編集後記 第9回・第10回を物語調に全面改稿し、インテリア編の第11〜13回を追加。著作権・裏方運営・使いやすい画面づくりを、会話とたとえを交えた読み物として整理しました。
2026年9月13日更新・v0.93：編集後記 第10回「表から見えない、裏方の仕事」を追加。締切・期日・進捗・公開予定を管理する裏方システムの考え方を記録しました。
2026年9月13日更新・v0.89：用語集を300語から360語へ拡張。Python・SQL・セキュリティ・コンピューターの基礎用語を追加しました。
2026年9月13日更新・v0.88：用語集を237語から300語に拡張。略称・説明・使用例・長音の表記違いの検索に対応。
JavaScript講座の物語形式を維持したまま、編集後記 第5〜8回も、実際の迷い・失敗・会話・気づきが伝わる読み物として作り直しました。Cloudflare公開、更新、Search Console、GoogleBot確認までの流れもストーリーとして残しています。
大学で学んだこと、実際に作って感じたこと、自分の強み、今につながった経験と今後の進め方を記録しています。
やさしく積み上げる学びを、落ち着いたカードで見やすく整理。
第1回「職場に、ものすごく速い新人が来た」
助手のJavaScriptくんと、指示・画面の役割・条件分岐を学ぶ物語。全3ページ。
掲載日：2026年9月12日
3つの技術を、基礎→使い方→実践の順に3話ずつ学びます。
追加日：2026年9月16日
「覚える」から「実際に画面を動かす」へ。笑いながら仕組みを理解する3回です。
追加日：2026年9月18日
私はプログラマーではありません。仕事の中で「もっと簡単にできないだろうか」と考えたことが、プログラミングに興味を持つきっかけでした。
見出し、文章、ボタンなどの骨組み。
色、文字、大きさ、配置などの見た目。
ボタンを押した後の動作や画面切替。
見た目ができても、ボタンが動かなければ完成ではありません。実際に押し、確認し、直すところまでを学習の一部にします。
<button>押してください</button><button>押してください</button>これだけでは、押した後に何をするのかが決まっていません。
<button id="hello">押してください</button>
<p id="result"></p>
<script>
document.getElementById('hello').addEventListener('click', function(){
document.getElementById('result').textContent='ボタンが動きました！';
});
</script>↑ 実際に押せます。
プログラム言語の世界・第6回
掲載日：2026年9月13日
プログラム村では、JavaScriptくんが毎日忙しく働いていました。
ボタンを押したら動く。文字を変える。画面を切り替える。計算する。とにかく仕事が速い。
でも、たまにやらかします。
自由です。自由すぎます。
そこへTypeScriptくんがやってきました。
面倒くさい。かなり細かい。でも言っていることは正しい。
数字なら数字、文字なら文字。TypeScriptくんは、仕事を始める前に確認したがるタイプでした。
TypeScriptはJavaScriptを土台にした言語です。JavaScriptを知っていると、「あ、親戚だな」と感じます。
ただしTypeScriptくんは、間違いそうなところを見ると先に注意します。
「そこ危ないですよ」「その値、違う型です」「その名前、本当にありますか？」
少し口うるさい。でも大きなシステムになるほど、この口うるささがありがたくなります。
部屋が一つなら鍵の管理も簡単です。でも100部屋ある建物で「だいたい合ってるでしょう」は怖い。
プログラムも同じ。小さなコードではJavaScriptの自由さが気楽でも、大きくなると「この荷物はどこの部屋？」が重要になります。
そこでTypeScriptくんが入口でチェックします。
警備員みたいなものかもしれません。
プログラム言語の世界・第7回
掲載日：2026年9月13日
ある朝、プログラム村に、きっちりスーツを着た人がやってきました。
Javaさんでした。
時間に正確。決まりを守る。書類もちゃんと書く。
「とりあえず文字を出して」と頼んでも、Javaさんは確認してきます。
「クラスは？」「入口はmainで？」「型は決まっていますか？」
Pythonくんなら、かなり早く仕事を始めてくれます。Javaさんは「会社なので書類が必要です」という顔をしています。
銀行、企業の業務システム、大きなWebサービス。人が多くなるほど「好き勝手に書かない」ことが大切になります。
Javaさんはそこが得意です。
自由な職人というより、組織に強い技術者。
Javaのコードを見ると、最初は「長いな」と感じることがあります。
でも、その中には型、構造、役割、ルールが入っています。
1人なら口約束でもいい。100人なら記録が必要。会社の仕事と同じです。
プログラム言語の世界・第8回
掲載日：2026年9月13日
今度は別の方向から、工具箱を持った職人がやってきました。
名前はC#さん。
見た目は少しJavaさんに似ています。
やっぱり。
C#さんはMicrosoftの世界と相性がいい職人です。
Windows、.NET、業務アプリ、Web、クラウド。かなり幅広く働けます。
また何でも屋が来ました。
C#はゲーム開発でも有名です。Unityでは長く中心的な言語として使われてきました。
キャラクターを動かす。スコアを計算する。当たり判定をする。ゲームのルールを書く。
普段は真面目な業務システムを作っているのに、別の日にはゲームを作っている。ギャップがすごい。
C#も型や構造を大切にします。それでいて便利な機能も多く、「そこまで全部手で書かなくてもいいですよ」と助けてくれる場面があります。
昼は会社の管理システム。夜はゲーム開発。なかなか働き者です。
TypeScriptは慎重派。Javaは組織派。C#は器用な万能派。
同じ「プログラムを書く」でも、得意な仕事が違う。だからプログラム言語は面白い。
変数、if文、関数。少しずつJavaScriptが分かってきたKAZUは、ちょっと調子に乗っていた。
ミニテスト10問の正解を保存しようと、answer1、answer2、answer3……と書き始める。5問、8問と進んだところで手が止まった。
let answer1 = "A";
let answer2 = "B";
let answer3 = "C";そこで登場したのが、たくさんのデータを一つにまとめる配列（Array）だった。
let answers = ["A", "B", "C"];配列は大きな棚のようなもの。Aを取り出すなら answers[0]。ここで重要なのは、配列は0から数えること。
answers[0] → A
answers[1] → B
answers[2] → Clet answers = [
"A", "B", "B", "A", "A",
"B", "A", "B", "A", "B"
];第1問は answers[0]、第10問は answers[9]。名前一覧、用語集、ミニテスト、献立、記事一覧――大量のデータを扱う場面で配列の考え方が役立つ。
今回の要点：変数は1つのデータを覚える。配列は、たくさんのデータを順番にまとめて覚える。一番最初は0番。
配列を覚えたKAZUは、今度は答えを全部表示しようとした。
console.log(answers[0]);
console.log(answers[1]);
console.log(answers[2]);そこでAIが出したのが for文。
for (let i = 0; i < 10; i++) {
console.log(answers[i]);
}let i = 0 は0から開始。i < 10 は10より小さい間続ける。i++ は1ずつ増やす。つまり0、1、2……9と進み、そのたびに answers[i] を処理する。
10回でも100回でも、同じ仕事を人間が書き続ける必要はない。
for (let i = 0; i < answers.length; i++) {
console.log(answers[i]);
}answers.length は配列の個数。問題が10問から50問に増えても、その個数に合わせて最後まで処理できる。
今回の要点：for文は同じ処理を繰り返す仕組み。人間がルールを作り、コンピュータに繰り返しを任せる。
変数、if、関数、配列、for。ここまで覚えたKAZUには一つ疑問があった。
<p id="message">ここが変わります</p>id="message" は目印。JavaScriptから次のように探せる。
document.getElementById("message");ざっくり言えば「このページの中から、messageというIDのものを探して」という命令だ。
document.getElementById("message").textContent =
"JavaScriptで変更しました！";これで画面の文字が実際に書き換わる。
<button onclick="changeMessage()">押してみる</button>function changeMessage() {
document.getElementById("message").textContent =
"成功しました！";
}HTMLが骨組みを作る。CSSが見た目を整える。JavaScriptが動きを与える。変数がデータを覚え、ifが判断し、functionが仕事をまとめ、配列が整理し、forが繰り返し、DOMがHTMLとJavaScriptをつなぐ。
プログラミングはコードを丸暗記することではない。「こうしたい」という人間の考えを、「こうしてください」というコンピュータの言葉へ変えていくことだ。
次回予告：習ったものを全部使って、自分で一つ作ってみる。物語は「ミニアプリ制作編」へ続く。
0 / 2 回 完了
配列・for文・DOM操作を10問で確認します。答えを選ぶと、その場で理由が表示されます。
ミニテストを番号順に整理しました。上から順番に進められます。
全12問。HTML・CSS・JavaScriptの役割から、在庫の判断まで。答えを選ぶと理由が分かります。
ヒントを見ても減点されません。
登録語彙を収録。略称・説明・使用例からも検索できます。名前・ひらがな・カタカナ・英字で探せます。用語を押すと説明と使用例が開きます。未入力なら全件表示します。
読み方の最初の文字を選んでください。が・ざ・だ・ば・ぱ行は、か・さ・た・は行に含みます。
登録語彙を読み込み中です。名前を入力すると候補が出ます。
候補がありません。別の文字や読み方を試すか、分類を「すべて」にしてください。
用語を選んでください。
サイト内で現在のページがどの階層にあるかを示す案内。
例：ホーム→学習→HTMLの順にリンクを並べます。
ブラウザのタブなどに表示する小さなサイトのアイコン。
例：サイトを見分けやすくする絵をタブに表示します。
本文やナビゲーションなど、ページの主要領域を識別する目印。
例：main要素で本文の領域を示します。
キーボード入力や操作の対象になっている状態。
例：Tabキーで次のボタンに移動します。
Tabキーで操作対象を移動するときの順番。
例：入力欄から送信ボタンへ自然な順で進めるか確認します。
文字と背景などの明るさの違いを比率で表したもの。
例：薄い灰色の文字を濃くして読みやすくします。
文章の行と行の間の空間。CSSではline-heightで行の高さを調整します。
例：本文のline-heightを1.8にして読みやすさを確認します。
要素が広がる幅の上限。CSSではmax-widthで指定します。
例：本文が横に長くなりすぎないようにします。
画像や領域の横幅と高さの比率。
例：横16に対して縦9の動画枠を作ります。
必要になるタイミングに近づいてからデータを読み込む方法。
例：画面の下にある画像にloading="lazy"を指定します。
展開すると元のデータを完全に復元できる圧縮。
例：文章ファイルをZIPで小さくして送ります。
一部の情報を減らして容量を小さくする圧縮。
例：写真をJPEGで保存すると画質と容量が変わります。
透明な部分を持つ画像。
例：背景を透明にしたPNGをページに置きます。
線や曲線などを図形の情報として表す画像。
例：ロゴを拡大しても輪郭を滑らかに表示します。
小さな点である画素を並べて表す画像。
例：写真を構成する画素の色を編集します。
図形や文字をXML形式で記述する画像形式。
例：円や線を使ったアイコンを作ります。
実行待ちの処理を順に取り出して実行につなげる仕組み。
例：タイマーの処理は現在の処理が終わった後に実行されます。
実行中の関数の呼び出し関係を積み重ねて管理する場所。
例：関数Aから関数Bを呼ぶとBの処理が上に積まれます。
使われなくなったメモリ領域を自動で回収する仕組み。
例：参照されなくなったオブジェクトの領域を再利用します。
同じ入力なら同じ結果を返し、外部の状態を変更しない関数。
例：二つの数を受け取って合計だけを返します。
戻り値を返す以外に、外部の状態を変えるなどの作用。
例：関数の中で画面を書き換えたりファイルを保存したりします。
作成したデータを後から変更しない性質や扱い方。
例：配列を直接変更せず、新しい配列を作ります。
外側を複製し、内側のオブジェクトなどは参照を共有するコピー。
例：配列を展開構文で複製しても中のオブジェクトは共有されます。
内側のデータも含めて独立した複製を作ること。
例：編集用データの変更が元の入れ子データへ影響しないようにします。
整列済みのデータで探索範囲を半分ずつ狭める探し方。
例：番号順の一覧で中央の番号と比較して探します。
データを先頭などから一つずつ調べる探し方。
例：商品一覧を順に見て目的の商品を探します。
最後に入れたものを最初に取り出すデータ構造。
例：積んだ皿を上から取る順番に似ています。
先に入れたものを先に取り出すデータ構造。
例：印刷の依頼を受付順に処理します。
条件が切り替わる境目の値。
例：注文数が1～10なら0・1・10・11の動作を確認します。
入力の誤りや通信失敗など、正常に進まない場合の処理。
例：保存に失敗したとき利用者に再試行を案内します。
想定どおりの条件で正常に進む処理。
例：必要事項を入力し、保存完了まで確認します。
同じ問題をもう一度起こすための操作の順番。
例：ページを開く→名前を入力する→保存を押す、と記録します。
外から見える動作を保ちながらコードの内部構造を整理すること。
例：重複する処理を一つの関数にまとめます。
コードの変更を確認し、問題点や改善点を検討すること。
例：保存処理の変更でデータが消えないか確認します。
設計や実装の選択により、将来の変更や保守に余分な手間がかかる状態。
例：応急処置を重ねた部分を後で整理する必要が生じます。
複数の列を組み合わせて行を一意に識別する主キー。
例：注文番号と明細番号の組で一行を識別します。
トランザクション内の未確定の変更を取り消す処理。
例：注文の保存途中で失敗したら一連の変更を取り消します。
複数の処理が同じ資源を同時に変更して衝突しないようにする仕組み。
例：在庫の同時更新で個数が不整合にならないようにします。
同じ操作を繰り返しても、一度行った場合と同じ結果になる性質。
例：状態を「完了」に設定する操作を二度行っても完了のままです。
システムが正常に応答するかを確認する仕組み。
例：定期的に確認用URLへアクセスして応答を調べます。
命令を読み取り、計算や制御を行う主要な処理装置。
例：プログラムの計算を実行します。
実行中のプログラムや作業データを一時的に置く記憶領域。
例：大きな画像を編集すると使用量が増えます。
ファイルなどを継続して保存する装置や領域。
例：HTMLファイルをSSDに保存します。
半導体メモリを利用する記憶装置。
例：OSやアプリ、作成したファイルを保存します。
磁気ディスクを利用する記憶装置。
例：写真やバックアップを保存します。
機器の資源を管理し、アプリを動かす基本ソフト。
例：WindowsやmacOS、iOSが該当します。
OSが実行中のプログラムを管理する単位。
例：起動したアプリがプロセスとして動きます。
プロセス内で処理を進める実行の単位。
例：複数のスレッドで仕事を分担します。
0か1の二つの状態で表す情報の単位。
例：8ビットでは256通りの状態を表せます。
通常8ビットで構成される情報量の単位。
例：ファイルの大きさをバイト数で確認します。
0と1を使い、2ごとに桁が上がる数の表し方。
例：二進数の101は十進数の5です。
0から9とAからFなどで16種類の数字を表す方式。
例：CSSの色指定#FF0000は赤を表します。
データを一定の方式で小さく表現すること。
例：複数のファイルをZIPにまとめます。
圧縮されたデータを展開して利用できる形に戻すこと。
例：ZIPからHTMLファイルを取り出します。
複数のファイルをまとめ、圧縮もできるファイル形式。
例：公開用ファイル一式をまとめて保管します。
内容を読むことはできるが変更できない状態。
例：元の帳票を読み取り専用で配布します。
コピーや切り取りをした情報を一時的に保持する仕組み。
例：コピーしたコードをエディタへ貼り付けます。
キーの組み合わせで操作を実行する仕組み。
例：多くのWindowsアプリではCtrl+Sで保存します。
画面のボタンやアイコンなどで操作する利用方法。
例：保存ボタンをクリックします。
文字の命令を入力して操作する利用方法。
例：ターミナルでpythonとファイル名を入力します。
オブジェクトの性質や振る舞いをまとめて定義すること。
例：class Product:で商品の型を作ります。
クラスなどをもとに作られた具体的なオブジェクト。
例：商品クラスから個別の商品を作ります。
既存のクラスなどの性質を引き継いで拡張する仕組み。
例：共通の帳票クラスから注文書クラスを作ります。
インスタンスメソッドで対象自身を受け取る引数の慣用名。
例：self.nameでそのインスタンスの名前を扱います。
通常、インスタンス生成時の初期化に使うメソッド。
例：受け取った商品名を属性へ保存します。
値がない状態などを表す特別な値。
例：検索結果がないことをNoneで返します。
条件の成立・不成立を表す真偽値。
例：在庫がある場合にTrueを設定します。
先の条件が成立しない場合に次の条件を調べる節。
例：在庫が少ない場合の分岐を追加します。
何もしないことを表す文。
例：作成途中の関数の本体に置きます。
例外を発生させる文。
例：不正な個数に対してValueErrorを発生させます。
値が指定した型やその派生型のインスタンスか調べる関数。
例：入力結果が文字列か確認します。
繰り返しの対象から番号と要素を順に得る関数。
例：材料一覧に1からの番号を付けます。
複数の反復可能な対象から要素を組にして取り出す関数。
例：商品名と個数を組にして処理します。圧縮形式のZIPとは別です。
要素を並べ替えた新しいリストを作る関数。
例：商品名を順に並べて表示します。
列などから範囲や間隔を指定して一部を取り出す操作。
例：Pythonでitems[0:3]と書くと先頭から3要素まで取得します。
文字列の中に式の値を埋め込む書き方。
例：f'残り{count}個'で個数を表示します。
関数やクラスに処理を適用して定義を包む仕組み。
例：関数の実行時間を記録する機能を追加します。
ファイルやフォルダのパスをオブジェクトで扱う標準モジュール。
例：Pathを使ってHTMLファイルを読み込みます。
行数やNULLでない値の数を数える集計関数。
例：COUNT(*)で注文の行数を数えます。
数値の合計を求める集計関数。
例：SUM(quantity)で注文個数を合計します。
数値の平均を求める集計関数。
例：AVG(price)で価格の平均を求めます。
検索結果の重複する組をまとめる指定。
例：担当者名を重複なしで取得します。
集計したグループに対して条件を指定する句。
例：合計個数が10以上のグループを表示します。
対応するデータベースで取得件数などを制限する句。
例：LIMIT 10で結果を最大10行にします。
文字列がパターンに合うか調べる演算子。
例：LIKE '紙%'で紙から始まる名前を探します。
値が不明または存在しないことなどを表す状態。
例：未入力の価格をIS NULLで探します。
列にNULLを保存できないようにする制約。
例：商品名の入力を必須にします。
列や列の組の値の重複を制限する制約。
例：商品コードを重複登録しないようにします。
データベースに新しい表を作る文。
例：商品名と個数を持つ注文表を作ります。
既存の表の構造などを変更する文。
例：商品表に備考の列を追加します。
入力などがSQL命令として解釈され、不正な操作につながる問題。
例：入力値をSQLへ直接連結せず、パラメーターとして渡します。
不正なスクリプトがWebページ内で実行される問題。
例：利用者の入力を文字として表示するときはtextContentを使います。
利用者の認証状態を悪用して意図しないリクエストを送らせる攻撃。
例：更新処理でCSRFトークンなどを検証します。
異なる種類の二つの要素で本人を確認する方式。
例：パスワードと手元の認証器を組み合わせます。
作業に必要な範囲だけ権限を与える考え方。
例：閲覧担当者には削除権限を付けません。
危険な構造などを用途に応じて除去・変換する処理。
例：許可するタグを限定してHTMLを扱います。
特別な意味を持つ文字を、その場に適した表現へ変えること。
例：HTMLの文章中で小なり記号を<と表します。
不正操作などにつながり得るシステムの弱点。
例：入力処理の欠陥を修正して更新します。
パスワードの生成や保管、入力を補助するソフト。
例：サービスごとに異なるパスワードを管理します。
本物を装ってパスワードなどをだまし取る行為。
例：ログイン前にアクセス先のドメインを確認します。
Gitリポジトリを共有し、変更の相談やレビューを行うサービス。
例：サイトのソースコードを保存し、修正内容を比較します。
ソースコードと変更履歴を管理する場所。
例：学習サイト専用のリポジトリを作ります。
変更を取り込んでもらうための提案。
例：用語集の追加をレビューしてから取り込みます。
リポジトリを履歴ごと手元に複製すること。
例：git cloneで作業用のコピーを作ります。
手元のコミットを遠隔リポジトリへ送る操作。
例：修正をコミットしてからgit pushします。
遠隔リポジトリの変更を取得して取り込む操作。
例：作業前に他の人の更新を取り込みます。
変更同士が競合し、自動で統合できない状態。
例：同じ行の別々の修正を確認して統合します。
変更を頻繁に統合し、自動テストなどで確認する開発習慣。
例：更新のたびに構文チェックを実行します。
利用者の操作の流れを端から端まで確認するテスト。
例：検索して用語の説明が開くまで確認します。
テストで期待する条件が成立するか確認する記述。
例：検索結果が1件以上あることを確認します。
テスト用に本物の処理を置き換える代用品。
例：外部APIの返答を固定して画面を確認します。
エラーに至る関数呼び出しの経路を示す情報。
例：エラーの行番号から原因の関数を探します。
デバッグ中に実行を一時停止する位置。
例：検索処理の途中で変数の値を確認します。
Web配信やネットワーク保護などを提供するサービス。
例：サイトをインターネットへ公開する用途に使います。
分散したサーバーからコンテンツを配信する仕組み。
例：画像を利用者に近い配信拠点から届けます。
ドメインの下に設ける名前の区分。
例：learn.example.comのlearnが該当します。
別のURLへ閲覧者を移動させる仕組み。
例：旧ページから新ページへ案内します。
要求したページなどが見つからないことを表すHTTP応答。
例：削除された記事のURLを開いたときに表示されます。
サーバー内部のエラーを表すHTTP応答。
例：サーバーの処理が失敗した場合にログを確認します。
通信の暗号化や相手の確認を行うプロトコル。
例：HTTPSで通信内容を保護します。
接続を保ちながら双方向に通信する仕組み。
例：チャットの新着メッセージを届けます。
APIなどの特定の機能にアクセスする接続先。
例：/api/termsから用語データを取得します。
URLの疑問符以降に付ける追加情報。
例：?q=htmlで検索語を渡します。
通信で送受信する主なデータ本体。
例：POSTで注文内容のJSONを送ります。
決めた時間内に処理が終わらず待機を打ち切ること。
例：応答が来ない通信を中止して案内を出します。
失敗した処理を再度試すこと。
例：通信失敗時に間隔を空けて再取得します。
一定時間内に利用できるリクエスト数などの制限。
例：短時間に大量のAPI呼び出しをしないようにします。
検索エンジンがページを理解しやすくする改善。
例：記事に内容の分かるタイトルを付けます。
サイト内のページ構成やURLをまとめた情報。
例：XML形式で検索エンジンにURLを知らせます。
クローラーに巡回ルールを伝えるファイル。
例：巡回対象を指定します。閲覧制限の代わりにはなりません。
HTML文書の文字コードや説明などを記す要素。
例：meta charsetで文字コードを指定します。
リンク共有時のタイトルや画像などを伝えるメタ情報。
例：SNSに記事の紹介画像を表示させます。
内容の意味に合ったHTML要素を使う書き方。
例：ナビゲーションをnav要素で囲みます。
文書の章や節の題名を表す要素。
例：h1をページの題名、h2を節の題名に使います。
別の文書や位置へ移動するための参照。
例：a要素のhrefに移動先を指定します。
箇条書きや番号付きの項目を表すHTML要素。
例：ulとliで材料一覧を作ります。
行と列を持つ表を表すHTML要素。
例：tableで発注品と個数を整理します。
状態などの条件で要素を選ぶCSSの仕組み。
例：:focusで入力中の欄を目立たせます。
要素の一部分などを装飾するCSSの仕組み。
例：::first-letterで最初の文字を装飾します。
競合するCSS宣言の優先順位を決める判断材料。
例：IDセレクターはクラスセレクターより詳細度が高くなります。
内容・内側余白・枠線・外側余白として要素を捉える考え方。
例：幅とpaddingを確認してはみ出しを直します。
要素の重なり順を指定するCSSプロパティ。
例：同じ重なりの文脈内で小窓を前面に出します。
領域からはみ出す内容の扱いを指定するCSSプロパティ。
例：overflow: autoで必要に応じスクロールさせます。
ルート要素の文字サイズを基準にする長さの単位。
例：文字サイズが16pxなら1.5remは24pxです。
繰り返し使う値に名前を付けるカスタムプロパティ。
例：--accentに色を置いてvar(--accent)で使います。
CSSの値の変化を一定時間かけて表示する仕組み。
例：ボタンの色をゆっくり切り替えます。
発生したイベントが親要素へ伝わる段階。
例：子ボタンのクリックを親の一覧で受け取ります。
親要素で子要素のイベントをまとめて扱う方法。
例：追加された用語ボタンも一覧側で処理します。
連続操作が落ち着いてから処理を実行する方法。
例：検索入力が止まってから検索します。
頻繁な処理の実行回数を一定間隔に抑える方法。
例：スクロール中の更新頻度を抑えます。
関数が作られた場所の変数を参照できる仕組み。
例：カウンター関数の内部で回数を保持します。
別のオブジェクトの性質を参照する仕組みの土台。
例：配列は共通のプロトタイプからmapを利用します。
nullやundefinedならアクセスを止める構文。
例：user?.nameで利用者がいない場合に備えます。
重複しない値を保持するコレクション。
例：new Setで同じ検索候補をまとめます。
キーと値の組を保持するコレクション。
例：用語IDから説明を探せるようにします。配列のmapとは別です。
JSON文字列をJavaScriptの値へ変換するメソッド。
例：保存したJSON文字列から配列を復元します。
JavaScriptの値をJSON文字列へ変換するメソッド。
例：注文データを文字列にして保存します。
同一オリジンでタブのセッション単位に値を保存する仕組み。
例：入力途中の選択内容を一時的に保持します。
ブラウザ内に構造化データを保存できるデータベース。
例：オフライン用の献立データを保存します。
ページとは別に動き、通信やキャッシュなどを扱う仕組み。
例：必要なファイルをキャッシュしてオフライン表示に使います。
Web技術でアプリのような利用体験を目指す仕組み。
例：ホーム画面から学習サイトを開ける構成にします。
関数の定義で受け取る値に付ける名前。
例：function greet(name)のnameが仮引数です。
関数を呼び出すときに渡す具体的な値。
例：greet('太郎')の太郎が実引数です。
ホームページの骨組みを作る言語。
見出し・文章・ボタンを置きます。厳密には、文書の構造を表すマークアップ言語です。
色、文字、大きさ、配置など見た目を整える。
ボタンを緑にしたり、文字を大きくしたりします。スタイルシート言語です。
ボタンや画面切替など、ページに動きを付ける。
数量を変えたら金額を計算する、という処理を書けるプログラミング言語です。
ホームページを見るためのアプリ。
SafariやChromeなど。HTML・CSSを表示し、JavaScriptも実行します。
将来、インターネット上でサイトやデータを届けるために使うコンピュータ。
ブラウザからの要求に応じてページを返すなど、サービスを提供します。サーバーソフトウェアを指す場合もあります。
集計や自動化など、さまざまな処理を書けるプログラミング言語。
複数のCSVファイルを読み、商品の合計数をまとめる処理などに使えます。
業務システムなどにも使われるプログラミング言語。
JavaScriptとは別の言語です。名前が似ていても、そのまま同じコードは使えません。
データベースの情報を検索・追加・更新するための言語。
発注履歴から、特定の日付の商品だけを取り出す、といった操作をします。
コンピュータに実行させる指示をまとめたもの。
在庫を確認し、足りなければお知らせする一連の指示。
プログラミング言語などの決まりに沿って書いた内容。
const 在庫 = 1; もコードの一部です。ソースコードとも呼びます。
コードを書くときの文法や並べ方の決まり。
JavaScriptの if の条件は丸括弧で囲みます。
コードの中に書く、人のための説明。
JavaScriptでは // の後に、その行の説明を書けます。処理としては実行されません。
値に名前を付けて扱う仕組み。
在庫という名前で1という数字を扱います。変更できるかどうかは宣言方法にもよります。
後から別の値を再代入できない変数を宣言する書き方。
const 在庫 = 1; の後に 在庫 = 2; とするとエラー。配列やオブジェクトの中身まで固定するわけではありません。
後から別の値を代入できる変数を宣言する書き方。
let 数量 = 1; の後に 数量 = 2; と書けます。
変数に値を設定すること。
数量 = 3; は、数量に3を設定します。JavaScriptの = は等しいかを調べる記号ではありません。
計算に使える数字の値。
300や2など。300 * 2 なら600になります。
文字を並べたデータ。
JavaScriptでは「洗剤」を "洗剤" のように引用符で囲みます。"300" も文字列です。
true（真）とfalse（偽）の2種類の値。
在庫 <= 2 のような比較の結果は、trueかfalseになります。
計算や比較などの操作を表す記号。
+ は足し算や文字列の連結、* は掛け算です。役割は記号や値の種類で変わります。
値の大小や一致を調べること。
在庫 <= 2 で、在庫が2以下か調べます。
境目の値を含めて大小を比べる記号。
2 <= 2 はtrue。3 <= 2 はfalse。>= は「以上」です。
型を自動変換せず、値が等しいかを調べる記号。
3 === 3 はtrueですが、3 === "3" はfalseです。
条件によって、実行する処理を変えること。
在庫が少なければ発注のお知らせ、足りていれば通常表示にします。
条件が成り立つ場合に処理するための書き方。
if (在庫 <= 2) { ... } は、2本以下のときに中の処理を実行します。
ifの条件が成り立たない場合の処理を書く部分。
「もし雨なら傘を持つ。そうでなければ持たない」の後半にあたります。
ひとまとまりの処理を、呼び出して使えるようにしたもの。
「金額を計算する」という仕事をまとめ、必要なときに呼び出します。
関数を定義する書き方の一つ。
function 返事する() { ... } と書くと、「返事する」という処理を定義できます。
関数を呼び出すときに渡す値。
計算する(300, 2) の300と2。単価と数量を処理へ渡すイメージです。
関数が呼び出し元へ返す値。
金額計算の関数から600を返し、画面表示などに使います。JavaScriptではreturnを使います。
複数の値を順番に並べて扱うもの。
["洗剤", "ゴミ袋", "手袋"] のような商品一覧を作れます。
名前と値の組をまとめて扱うもの。
{商品名: "洗剤", 単価: 300} のように、一つの商品に関する情報をまとめます。
同じような処理を複数回実行すること。
商品の一覧を順番に調べ、金額を合計する場面などで使います。
繰り返しを書くための構文。
JavaScriptで for (let i = 0; i < 3; i++) { ... } は、中の処理を3回行います。
HTMLで要素を表すための記述。
<p>文章</p> の <p> と </p> は、段落の開始と終了を表すタグです。
HTML要素に付ける設定や補足情報。
<p id="伝言"> の id="伝言" は属性です。
HTML要素に付ける、ページ内で一意の目印。
id="伝言" として、JavaScriptからその部品を探せます。同じページ内で重複させません。
複数のHTML要素に共通の名前を付ける属性。
同じclassのボタンをCSSでまとめて緑にする、といった使い方をします。
クリックや入力など、処理を始めるきっかけになる出来事。
ボタンがクリックされたら、計算処理を呼び出します。
クリックされたときの処理を指定するための属性やプロパティ。
HTMLでは onclick="返事する()" のように書けます。
イベントが起きたときに呼び出す処理を登録するメソッド。
ボタンにclickイベントの処理を登録し、押されたときに実行させます。
HTMLなどの文書を、プログラムから操作できる構造として表したもの。
JavaScriptで画面の文章を書き換えるとき、DOMの要素を操作します。
指定したidを持つ要素を取得するメソッド。
document.getElementById("伝言") で、その目印の部品を探します。見つからなければnullを返します。
要素の文字の内容を読み書きするプロパティ。
textContent = "600円です" とすると、その要素の文字が変わります。
ブラウザにメッセージのダイアログを出す関数。
alert("発注してください") と書くと、お知らせが出ます。
ブラウザ内に文字列データを保存する仕組み。
学習進捗の保存などに使えます。別端末への自動共有はなく、ブラウザのデータ削除などで消えることがあります。
情報を整理して保存し、検索や更新を行えるようにしたもの。
商品や発注履歴を管理します。ブラウザ内の保存とは別の仕組みもあります。
意図した結果にならない、プログラムの不具合。
2本以下で知らせたいのに、2本以上で知らせてしまうのもバグです。
不具合の原因を調べて直す作業。
入力した数字と計算結果を確かめ、間違った条件式を修正します。
期待した結果になるか、実際に確かめること。
2本以下で発注するルールなら、2本と3本などを入れて比較します。
別のプログラムから機能を利用するための窓口や取り決め。
翻訳サービスに文章を送り、訳文を受け取る。
JavaScriptに型を扱う仕組みを加えた言語。
金額を入れる変数に文字を渡すミスを開発中に見つける。
メモリや機器に近い処理も記述できる言語。
組み込み機器の制御プログラムを書く。
C言語を基礎に、クラスなどの機能を備えた言語。
高速な画像処理やゲームの処理を書く。
.NETなどで利用されるプログラミング言語。
デスクトップアプリを作る。
Apple製品向けアプリの開発などに使われる言語。
iPhone向けの記録アプリを作る。
簡潔な文法と並行処理の仕組みを備えた言語。
多数の要求を受けるサーバーを作る。
所有権の仕組みによりメモリ安全性を重視する言語。
高速なファイル処理ツールを作る。
オブジェクトを中心に処理を書く言語。
Webアプリの処理を書く。
Webサーバー側の処理などに使われる言語。
フォームの入力をサーバーで処理する。
Javaとの相互利用が可能な言語。
Android向けアプリを作る。
人がプログラミング言語で書いた指示の文章。
エディタでindex.htmlを開いて読む。
問題を解くための手順。
金額が小さい順に商品を並べる。
行頭を字下げして構造を分かりやすくすること。
条件分岐の中を一段下げて書く。
ソースコードを別の実行形式などへ変換すること。
TypeScriptをJavaScriptへ変換する。
プログラムを解釈して実行する仕組み。
Pythonの処理系でスクリプトを実行する。
プログラムを動かすためのソフトや設定。
ブラウザでJavaScriptを動かす。
処理系に実行させるプログラム。
毎日の集計処理をファイルに書く。
文章やソースコードを編集するソフト。
HTMLの見出しを書き換える。
文字でコマンドを入力し、結果を見る画面。
python app.py を入力する。
操作を実行するための命令。
フォルダの中身を一覧表示する。
ファイルやフォルダの場所を表す文字列。
images/logo.pngで画像の場所を指定する。
基準の場所から見たファイルの位置。
同じフォルダのstyle.cssを指定する。
起点からの場所を省略せず表したパス。
/home/user/data.csvのように指定する。
ファイル名の末尾で種類を示す部分。
.htmlはHTMLファイルに使われる。
ファイルをまとめて整理する場所。
公開するファイルをpublicにまとめる。
文字と数値の対応を定めた仕組み。
UTF-8で日本語の文章を保存する。
Unicodeの文字をバイト列として表す方式の一つ。
HTMLのcharsetにUTF-8を指定する。
世界の文字などに共通の番号を割り当てる規格。
日本語と英語を同じ文書で扱う。
文字コードの解釈の違いなどで文字が正しく表示されない状態。
日本語のCSVを違う文字コードで開くと起こり得る。
小数部分を持たない数。
在庫数を9として扱う。
仮数と指数で表す数値形式。丸め誤差が生じることがある。
0.1と0.2の和が厳密な0.3にならない場合がある。
データを別の型へ変換すること。
文字列の「12」を数値12へ変える。
値が意図的に存在しないことを表す値。
未選択の商品をnullで表す。
値がまだ設定されていない場合などに現れる値。
未代入の変数を読むとundefinedになる。
数値として有効でない演算結果などを表す値。
Number('abc')の結果を確認する。
条件の組み合わせや否定を表す演算子。
在庫不足かつ対象商品なら発注する。
割り算で生じる余り。
7 % 3の結果は1。
変数などの名前を参照できる範囲。
関数の中だけで使う変数を作る。
プログラムの広い範囲から参照できる変数。
複数の関数が同じ設定値を参照する。
関数など、限定された範囲で使う変数。
集計関数の中だけで合計を保持する。
変更しない値や、再代入できない名前。言語により意味が異なる。
JavaScriptのconstは再代入を禁止する。
条件が成立する間、処理を繰り返す構文。
未処理のデータがある間、読み取りを続ける。
ループなどから途中で抜ける命令。
目的の商品が見つかったら検索を終える。
ループの残りを飛ばし、次の繰り返しへ進む命令。
空欄の行を飛ばして次の行を読む。
関数の実行を終え、呼び出し元へ値などを返す命令。
計算した合計金額を返す。
値に応じて処理を分ける構文。
選ばれた画面名に応じて表示を切り替える。
関数が自分自身を呼び出すこと。
フォルダの中のフォルダを順番に調べる。
処理中の問題を通常の流れと別の経路で伝える仕組み。
存在しないファイルを開いた際の問題を扱う。
例外が発生する可能性のある処理を囲む構文。
ファイル読み込みの失敗に備える。
try内などから伝わった例外を受け取って処理する構文。
通信失敗を画面に表示する。
tryに関連する処理の終了時に実行する節。
成功・失敗にかかわらず後片付けを行う。
矢印記号を使った関数の書き方。通常の関数とはthisの扱いなどが異なる。
x => x * 2で値を2倍にする。
別の処理に渡し、その処理から呼び出してもらう関数。
クリックされた時に実行する関数を渡す。
非同期処理の完了や失敗を表すオブジェクト。
通信が終わってから結果を扱う。
Promiseを返す非同期関数を定義するキーワード。
async functionで通信処理を書く。
Promiseの結果を待って処理を進めるための構文。
await fetch(url)で応答を受け取る。
完了を待つ間も別の処理を進められる実行方式。
データ取得中も画面操作を受け付ける。
処理の完了を待って次へ進む方式。
計算した結果を次の計算に使う。
HTTP通信などでデータを取得するAPI。
JSONファイルを読み込む。
文字列で構造化データを表す形式。
商品名と数量を一組のデータにする。
項目をカンマなどで区切った表形式のテキスト。
在庫表を表計算ソフトと受け渡す。
文字の並びのパターンを表す記法。
数字だけの入力かを調べる。
バッククォートで囲み、式を埋め込める文字列の記法。
商品名を含む案内文を組み立てる。
配列やオブジェクトの中身を取り出して代入する書き方。
商品データから名前と価格を取り出す。
配列の要素などを展開する構文。
二つの配列を一つにまとめる。
配列の各要素を変換した新しい配列を作るメソッド。
各商品の税込価格の配列を作る。
条件を満たす要素の新しい配列を作るメソッド。
在庫不足の商品だけを取り出す。
配列の要素を順番に処理し、一つの結果へまとめるメソッド。
明細の金額を合計する。
条件を満たす最初の配列要素を返すメソッド。
商品番号が一致する商品を探す。
配列の要素を並べ替えるメソッド。元の配列も変わる。
価格の昇順に並べる。
配列の末尾に要素を追加するメソッド。
注文リストに商品を加える。
配列や文字列に指定した値が含まれるかを調べるメソッド。
商品名に「洗剤」があるか調べる。
CSSセレクターに一致する最初の要素を取得するメソッド。
画面の入力欄を取得する。
CSSセレクターに一致する要素の一覧を取得するメソッド。
すべての商品ボタンを取得する。
新しいHTML要素などを作るメソッド。
検索結果用のボタンを作る。
要素などを子ノードとして末尾へ追加するメソッド。
作ったボタンを結果欄へ入れる。
要素のCSSクラスを操作するための仕組み。
選択中のボタンに色を付ける。
要素の内側をHTML文字列として取得・設定するプロパティ。
信頼できる固定HTMLを表示する。未確認の入力は直接入れない。
キャンセル可能なイベントの既定動作を止めるメソッド。
フォーム送信による画面遷移を止める。
指定時間が過ぎた後に処理を実行できるよう予約する関数。
保存完了メッセージを後で消す。
一定間隔で処理を繰り返すよう予約する関数。
画面の時計を定期的に更新する。
開発者向けコンソールに値を出力するメソッド。
計算途中の合計を確認する。
CSSで装飾対象の要素を指定する記法。
.cardでカードに同じ装飾を付ける。
オブジェクトが持つ値の名前や、CSSの設定項目。
CSSのcolorで文字色を指定する。
オブジェクトなどに属する呼び出し可能な処理。
配列のpushで要素を追加する。
要素や内容の周囲に設ける空間。
ボタンを離して押し間違いを減らす。
要素の外側の余白を指定するCSSプロパティ。
カード同士の間隔を空ける。
要素の枠と内容の間の余白を指定するCSSプロパティ。
ボタン内の文字の周囲を広げる。
要素の境界線を指定するCSSプロパティ。
入力欄を緑色の線で囲む。
主に一方向へ要素を配置するCSSの仕組み。
メニューを横並びにする。
行と列を使って要素を配置するCSSの仕組み。
ひらがな表を五列に並べる。
画面幅などに応じて表示を調整する設計。
スマートフォンではカードを一列にする。
画面幅などの条件でCSSを適用する仕組み。
狭い画面で文字サイズや列数を変える。
Webページを表示する領域。
画面幅に合わせてページを配置する。
入力情報をまとめて扱うHTMLの仕組み。
担当者名と発注数を入力する。
文字や数値などを入力するHTML要素。
数量を入力する欄を作る。
入力欄に対応する説明を示すHTML要素。
担当者名の入力欄に見出しを付ける。
選択肢から項目を選ぶHTML要素。
翻訳する言語を選ぶ。
押して操作するHTML要素。
保存を実行するボタンを作る。
対話用の小窓を表すHTML要素。
用語の説明を小窓で開く。
さまざまな人が情報や機能を利用できるようにすること。
キーボードだけでもボタンを操作できるようにする。
画像の内容や役割を文字で伝える説明。
ロゴ画像のaltにサイト名を書く。
Webの要求と応答をやり取りする通信プロトコル。
ブラウザがページを要求する。
TLSで保護されたHTTP通信。
通信内容を暗号化して送受信する。
Web上などの資源の場所とアクセス方法を表す文字列。
公開ページのアドレスを共有する。
インターネット上の名前の階層を構成する識別名。
example.comという名前を使う。
ドメイン名に対応する情報を問い合わせる仕組み。
名前からサーバーのIPアドレスを調べる。
IPネットワークで通信先などを識別するアドレス。
通信するサーバーを指定する。
相手のシステムへ送る要求。
商品一覧を取得したいとサーバーへ伝える。
要求に対して返される応答。
商品一覧のJSONを受け取る。
主に資源の取得に使うHTTPメソッド。
記事の内容を読み込む。
資源にデータを送り処理を求めるHTTPメソッド。
注文内容を送信する。
HTTP応答の結果を表す三桁の番号。
404は対象の資源が見つからないことを表す。
再利用のためにデータを一時的に保持する仕組み。
同じ画像の再取得を減らす。
ブラウザが保持し、条件に応じて通信に付ける小さなデータ。
ログイン状態の識別に使う。
一連の操作や通信を関連付けて扱う単位。
ログイン後の操作を同じ利用者として扱う。
別のオリジンへのブラウザ通信で応答の読み取り許可を管理する仕組み。
外部APIの応答を読み取れるかをサーバーが指定する。
URLのスキーム・ホスト・ポートの組み合わせ。
異なるドメインのページは異なるオリジンになる。
用意されたHTMLなどを配信する方式のサイト。
index.htmlをアップロードして公開する。
要求やデータに応じて内容を生成するサイト。
利用者ごとに注文履歴を表示する。
主に利用者の画面や操作を担当する部分。
検索欄と検索結果の表示を作る。
主にサーバー側でデータ処理などを担当する部分。
注文をデータベースに保存する。
サイトなどを動かし配信する環境を提供すること。
公開用ファイルを配信サービスに置く。
プログラムやファイルを実行・公開環境に配置すること。
修正版を公開環境へ反映する。
復元に備えてデータのコピーを保管すること。
更新前のHTMLを別名で残す。
変更の履歴を記録して管理すること。
以前の内容との差分を確認する。
ファイルの変更履歴を管理する分散型システム。
修正内容をコミットとして記録する。
Gitなどで変更のまとまりを履歴に記録すること。
用語追加を一つの変更として残す。
変更履歴を分岐させる仕組み。
公開版とは別に修正作業を進める。
分岐した変更を統合すること。
修正した内容を公開用ブランチへ取り込む。
二つの内容の違い。
追加した用語だけを確認する。
変更前の状態に戻すこと。
不具合があれば直前の公開版へ戻す。
関数などの小さな単位で動作を確かめること。
合計計算関数に既知の値を渡す。
複数の部分を組み合わせて動作を確かめること。
入力から保存までの連携を確認する。
変更後に既存機能が壊れていないか確かめること。
用語追加後も編集後記が開くかを確認する。
入力などが条件を満たすか検証すること。
数量が負数ではないことを確認する。
操作や処理の記録。
保存日時と担当者を残す。
利用者などが誰であるかを確認すること。
パスワードなどで本人を確認する。
誰が何の操作をできるかを判断すること。
管理者だけに商品削除を許可する。
鍵を使い、元の情報を読み取りにくい形へ変換すること。
通信内容を保護する。
データから一定の規則で計算した値。
ファイルが変わっていないか確認する。
実行環境からプログラムへ渡す設定値。
接続先をコードとは別に設定する。
API利用者やプロジェクトを識別するための文字列。
外部サービスの利用を管理する。秘密のキーは公開HTMLへ書かない。
データベースで行と列からなるデータのまとまり。
商品マスターを保存する。
表の一行に相当するデータ。
一商品の名前・価格・番号をまとめる。
表の列に相当する項目。
商品名の列を設ける。
各行を一意に識別するための列や列の組み合わせ。
商品IDで商品を区別する。
他の表のキーとの対応を制約として扱う仕組み。
注文明細の商品IDを商品マスターへ対応させる。
データの検索を効率化するための補助構造。
商品番号で探す処理を速くする。
データを問い合わせるSQL文。
必要な商品の名前と価格を取り出す。
対象とする行の条件を指定するSQLの句。
在庫が2以下の商品を検索する。
表に行を追加するSQL文。
新しい商品を登録する。
表の既存の行を更新するSQL文。
特定商品の価格を変更する。
表から行を削除するSQL文。
指定したテストデータを削除する。
複数の表の行を条件に従って結び付ける仕組み。
注文表に商品名を組み合わせる。
同じ値などで行をまとめ、集計するための句。
商品別に注文数を合計する。
結果を並べる順序を指定する句。
注文日が新しい順に表示する。
複数の処理を一つのまとまりとして扱う仕組み。
注文保存と在庫更新をまとめて確定する。
順序を持つ要素の集まりを扱う型。
商品名を複数まとめて保持する。
キーと値を対応させて保持する型。
商品番号から商品名を取り出す。
要素の並びを変更できないシーケンス型。
座標の二つの値をまとめる。
重複しない要素を扱う型。
重複する商品番号をまとめる。
関数を定義するキーワード。
合計を返す関数を定義する。
文字や値を出力する関数。
計算した金額を表示する。
要素数や長さを求める関数。
用語の登録数を数える。
整数の並びを表すオブジェクトを作る仕組み。
for文で10回繰り返す。
例外を受け取って処理する節。
ファイルがない場合に案内を出す。
資源の開始・終了処理などを管理する構文。
読み終わったファイルを閉じる。
モジュールなどを読み込んで利用する構文。
CSVを扱う機能を読み込む。
機能をまとめて分けたプログラムの単位。
計算処理を別ファイルにまとめる。
関連するコードなどをまとめて配布・管理する単位。
必要な機能をまとめて導入する。
再利用できる関数や機能の集まり。
既存のCSV読み込み機能を使う。
アプリの構成や処理の流れを支える共通の土台。
決められた構成に沿ってWebアプリを作る。
プロジェクトごとにパッケージなどを分ける環境。
別の開発で使うライブラリの版を分離する。
Pythonパッケージを導入・管理するツール。
必要なパッケージをインストールする。
繰り返しや条件を使ってリストなどを簡潔に作る書き方。
各商品の価格を2倍にしたリストを作る。
値を順番に取り出すための仕組み。
データを一件ずつ処理する。
値を必要に応じて順番に生成する仕組み。
大量の行を一度に保持せず扱う。
目的に合わせて表現や構造を一定の形へそろえること。
検索前に全角英数字を半角へそろえる。
漢字や英字の読み方を表す情報。
Pythonに「ぱいそん」を登録して検索する。
指定した文字列を一部に含むかで調べる方式。
「すくりぷと」でJavaScriptを探す。
値が全体として一致するかを調べる方式。
商品番号が完全に同じものを探す。
先頭の文字列が一致するかを調べる方式。
「あ」で始まる読み方の用語を探す。
多数の結果を複数のページに分ける仕組み。
検索結果を50件ずつ表示する。
条件を加えて対象を限定すること。
Pythonの用語だけを表示する。
同じものが複数ある場合にまとめること。
同じ用語を二重登録しないようにする。
① HTMLにボタンがあるか → ② JavaScriptが読み込まれているか → ③ idなどの名前が一致しているか、の順に確認します。
保存したファイルが最新か、ブラウザで再読み込みしたかを確認します。
50代・介護の仕事をしながら、AIと一緒にプログラミングをゼロから勉強しています。実際に作り、失敗し、修正する過程も含めて、このサイトで紹介していきます。
大学では一通り勉強しました。ただ、その頃は学んだことを生活や仕事に取り入れようとは考えていませんでした。
今は仕事の中で感じる不便を、仕組みにして解決したいと思うようになりました。学びと経験が、今になってつながり始めています。
このサイトは、最初から巨大なSNSを作るのではなく、完成した「建物」を一つずつ増やしていきます。
記事・用語集・テスト
作ったプログラム・実践例
12月課題。作品と制作過程を展示。
将来。投稿・コメント・作品交流。
第1回・第2回から記事を積み上げ、スマホ表示、翻訳、用語集、進捗、編集後記を安定させます。公開目標は2026年10月11日前後。
記事間の導線、検索しやすさ、読みやすさ、作品ページの整理を進めます。公開後に実際に使って見つかった問題も直します。
ホームページ画面、システム画面、試作→修正→完成の変化、イメージ作品などを展示できる場所を作ります。
Facebookをそのまま再現するのではなく、学習記録・作品投稿・コメントなど、このサイトに必要な機能から小さく試します。
ユーザー登録、プロフィール、作品展示、反応・交流などを検討します。必要になった段階でサーバー、データベース、認証、プライバシー対策を本格的に学びます。
広告だけを目的にせず、まず役に立つ記事と作品を蓄積します。その後、教材、テンプレート、小規模ツール、サポートなど、サイトの内容と自然につながる方法を検討します。
JavaScript講座・全10回 / 第2回 / 1ページ目（全3ページ）
掲載日：2026年9月13日
第1回で、「在庫が2本以下なら知らせる」という仕事を任されたJavaScriptくん。
翌日、KAZUはもう一つ仕事を頼むことにしました。
さすがに、このくらいの計算なら人でもできます。
でも、商品が10種類、20種類、100種類になったらどうでしょう。
単価が違い、数量も違い、最後に全部の合計を出す。人が電卓で一つずつ計算すれば、時間もかかりますし、入力ミスも起きます。
KAZUは考えました。
そこで、最初の仕事を渡します。
const 商品名 = "洗剤";
const 単価 = 300;
const 数量 = 2;
const 金額 = 単価 * 数量;JavaScriptくんの返事は、こうです。
ここで大事なのは、単に「300 × 2」と書いていないことです。
商品名、単価、数量、金額。
数字に意味のある名前を付けています。
たとえば、次のコードでも計算はできます。
const a = 300;
const b = 2;
const c = a * b;でも、数日後に見たとき、aが何で、bが何だったのか思い出せるでしょうか。
仕事でも、「あれ」「それ」「いつものやつ」では、新しく入った人には伝わりません。
プログラムも同じです。
「単価」「数量」のように意味が分かる名前を付けておけば、人が読み直したときにも分かりやすくなります。
今回のポイント：JavaScriptに仕事を頼むときは、数字だけでなく「何の数字なのか」まで名前を付ける。
ところが、ここでKAZUは一つ気づきました。
そうです。
JavaScriptくんが頭の中で600円と計算しても、画面に出さなければ、使う人には分かりません。
次は、計算結果を画面へ出してもらいます。
JavaScript講座・全10回 / 第2回 / 2ページ目（全3ページ）
掲載日：2026年9月13日
KAZUは、JavaScriptくんにもう一度頼みました。
ここで、HTMLさんの出番です。
HTMLさんは、結果を表示する場所を用意します。
<p id="結果">ここに金額が出ます</p>「結果」という目印を付けました。
するとJavaScriptくんは、その場所を探して文字を書き換えます。
document.getElementById("結果").textContent =
商品名 + "：" + 金額 + "円";画面には、
洗剤：600円
と表示されます。
| 担当 | 仕事 |
|---|---|
| HTMLさん | 結果を表示する場所を作る |
| JavaScriptくん | 計算して、その場所の文字を書き換える |
ここで、前回の第1回と同じ考え方が出てきます。
画面の部品があることと、その部品が動くことは別です。
HTMLで表示場所を作り、JavaScriptでそこに結果を入れる。
この役割分担がつながって、初めて利用者に結果が伝わります。
ここまでの仕事を、3つに分けるとこうなります。
KAZUは、発注システムの画面を思い出しました。
ここで、また一つ問題が出ます。
利用者が数量に「2」ではなく、空欄や文字を入れたらどうなるのでしょう。
JavaScriptくんは、指示されたとおり計算しようとします。
でも、正しく計算できない入力なら、こちらで止める仕組みが必要です。
次は、動く機能を「使える機能」に近づけます。
JavaScript講座・全10回 / 第2回 / 3ページ目（全3ページ）
掲載日：2026年9月13日
KAZUは、数量入力欄を作りました。
1、2、3……と数字を入れれば、計算できます。
ところが、試しに空欄のままボタンを押してみました。
今度は文字を入れてみます。
ここで分かるのは、正しい入力だけで動作確認してはいけないということです。
実際の利用者は、こちらが想定したとおりに入力してくれるとは限りません。
空欄かもしれない。0かもしれない。マイナスの数字かもしれない。文字かもしれない。
そこで、計算する前に確認します。
const 数量 = Number(入力欄.value);
if (!Number.isFinite(数量) || 数量 < 0) {
結果.textContent = "数量を正しく入力してください";
} else {
結果.textContent = "合計：" + (単価 * 数量) + "円";
}今は細かい記号を全部覚えなくても大丈夫です。
やっていることは、
という3段階です。
| 入力 | 確認すること |
|---|---|
| 1 | 300円になるか |
| 2 | 600円になるか |
| 0 | 0円として扱うか、入力を促すか |
| 空欄 | エラー表示になるか |
| 文字 | 間違った金額を出さないか |
KAZUは、ここで少し考え方が変わりました。
これが、実際に使うプログラムを作るときの大切な確認です。
第2回まとめ：JavaScriptくんは計算が速い。ただし「何を入力として受け取るか」「間違った入力をどう扱うか」は、人が決めてあげる必要があります。
次回は、JavaScriptの中で何度も登場する「変数」にもう少し踏み込みます。
JavaScriptくんの机の上には、名前の付いた箱が並び始めます。
JavaScript講座・全10回 / 第3回 / 1ページ目（全3ページ）
掲載日：2026年9月13日
電卓係として働き始めたJavaScriptくん。
今度は、KAZUが在庫の数字を管理してほしいと頼みます。
let 在庫 = 3;ここで登場するのが、変数です。
初心者向けには「名前付きの箱」と説明されることがあります。
「在庫」という名前の箱に3が入っている、と考えるとイメージしやすいからです。
そして1本使ったので、こうします。
在庫 = 在庫 - 1;すると、在庫は2になります。
KAZUは少し不思議に思いました。
確かに、数学の「=」なら左右が等しいという意味です。
でもJavaScriptでは、ここでの「=」は右側を計算して、その結果を左側へ入れるという意味です。
「今の在庫3から1を引いて、その結果2を、在庫という名前に入れ直す」。
そう読むと理解しやすくなります。
ただし、ここでも第1回と同じ注意があります。
棚から本当に1本使っただけでは、JavaScriptの在庫は勝手に2にはなりません。
人がボタンを押す、数量を入力する、バーコードを読むなど、現実の変化をプログラムへ伝える仕組みが必要です。
今日の第一歩：変数は、現実の情報をプログラムの中で扱うための「名前付きの値」。現実が変わったら、その変化をプログラムにも伝える。
JavaScript講座・全10回 / 第3回 / 2ページ目（全3ページ）
掲載日：2026年9月13日
JavaScriptくんの机には、いろいろな情報が並び始めました。
現在の在庫、最低在庫、税率、数量。
KAZUは全部同じように作ろうとしました。
let 税率 = 0.10;
let 最低在庫 = 2;
let 数量 = 1;これでも動きます。
でも、AIが一つ質問しました。
そこで、変えないものは const、変わるものは let と考えてみます。
const 税率 = 0.10;
const 最低在庫 = 2;
let 数量 = 1;constで作った名前に、あとから別の値を再代入しようとするとエラーになります。
const 最低在庫 = 2;
最低在庫 = 5; // エラー一方、letなら変更できます。
let 数量 = 1;
数量 = 2;最初は、何でもletにした方が自由で便利に見えます。
でも、変える必要のない値まで変えられると、後から思わぬところで書き換わる可能性が増えます。
仕事でも、変更してよい欄と、勝手に変えてはいけない基準があります。
プログラムでも同じです。
設計のコツ：文法を覚えるより、「この値は途中で変わるのか？」と考える習慣を持つ。
JavaScript講座・全10回 / 第3回 / 3ページ目（全3ページ）
掲載日：2026年9月13日
ある日、KAZUは少し前に書いたコードを見返しました。
const a = 300;
const b = 2;
const c = a * b;書いた本人なのに、分かりません。
そこで、名前を変えてみます。
const 単価 = 300;
const 数量 = 2;
const 合計金額 = 単価 * 数量;今度は、コードを読むだけで意味が分かります。
これは小さな違いですが、コードが長くなるほど効いてきます。
プログラムは、機械が実行できればいいように見えます。
でも実際には、人間も何度も読みます。
不具合が出たとき。機能を追加するとき。数週間後に続きを作るとき。
そこで、名前の付け方が重要になります。
たとえば発注システムなら、
のように、意味が分かる名前にしておくと、後で見直しやすくなります。
もちろん、短い名前が必ず悪いわけではありません。
ただ、初心者のうちは、意味の分かる名前を付けた方が、自分でコードを説明しやすくなります。
その通りです。
第3回まとめ：変数は値を扱うための仕組み。大切なのは、何を表す値か、途中で変わるか、名前を見て意味が分かるかです。
次回は、JavaScriptくんに「判断」をもっと本格的に任せます。
そして、たった1文字の記号が結果を逆にしてしまう怖さも体験します。
JavaScript講座・全10回 / 第4回 / 1ページ目（全3ページ）
掲載日：2026年9月13日
KAZUは、在庫管理のルールをJavaScriptくんに説明しました。
コードはこうなります。
if (在庫 <= 2) {
表示 = "発注が必要です";
}ここで使われている <= は「以下」です。
つまり、2本ちょうども含みます。
ところが、KAZUは試しにこう書き換えました。
if (在庫 < 2) {
表示 = "発注が必要です";
}今度は「2本未満」です。
すると、在庫が2本のときには発注の表示が出ません。
JavaScriptくんは間違っていません。
書かれた指示どおりに動いています。
間違えたのは、人間側の条件です。
条件式を書く前に、日本語でルールを書いてみます。
ここまで書けば、「2を含める」ことがはっきりします。
第4回の第一歩：記号から考えず、先に「どの数字なら、どの結果にしたいか」を決める。
JavaScript講座・全10回 / 第4回 / 2ページ目（全3ページ）
掲載日：2026年9月13日
KAZUは、在庫0本と10本でテストしました。
0本なら「発注が必要です」。
10本なら「在庫は足りています」。
どちらも正しく見えます。
KAZUは、そこで初めて境目を試します。
| 在庫 | 期待する結果 |
|---|---|
| 1本 | 発注が必要 |
| 2本 | 発注が必要 |
| 3本 | 在庫は足りている |
もし条件が 在庫 < 2 なら、2本のところだけ間違います。
0本と10本しか試していなければ、このバグには気づけません。
条件分岐では、切り替わる境目の数字が特に重要です。
最低在庫が2なら、
を試します。
これは、発注システムだけではありません。
「18歳以上」「100点未満」「期限まで3日以内」など、条件があるところでは同じ考え方が使えます。
テストのコツ：条件の境目、その1つ下、その1つ上。この3つをまず試す。
JavaScript講座・全10回 / 第4回 / 3ページ目（全3ページ）
掲載日：2026年9月13日
在庫表示を、もっと分かりやすくしたいとKAZUは考えました。
0本なら「在庫切れ」。
1〜2本なら「発注が必要」。
3本以上なら「在庫あり」。
JavaScriptくんに頼みます。
if (在庫 === 0) {
表示 = "在庫切れ";
} else if (在庫 <= 2) {
表示 = "発注が必要";
} else {
表示 = "在庫あり";
}ここで重要なのは、条件の順番です。
0本は「2本以下」にも当てはまります。
だから、先に「0本か」を確認しています。
もし「2本以下」を先に書けば、0本でも「発注が必要」となり、「在庫切れ」という特別な表示まで進みません。
KAZUは、紙にこう書きました。
| 在庫 | 表示 | 色 |
|---|---|---|
| 0 | 在庫切れ | 赤 |
| 1〜2 | 発注が必要 | 黄 |
| 3以上 | 在庫あり | 緑 |
先に表があれば、コードにしたときの確認もしやすくなります。
これは、現在作っている在庫管理の「緑・黄・赤」の考え方にもつながります。
第4回まとめ：if文は「判断」を任せる仕組み。大切なのは、条件の意味、境目の確認、そして複数条件の順番です。
次回は、商品が増えてきます。
KAZUはJavaScriptくんに100個の商品の確認を頼もうとします。
そして、「同じことを100回書くの？」という問題にぶつかります。
JavaScript講座・全10回 / 第5回 / 1ページ目（全3ページ）
掲載日：2026年9月13日
ある日、KAZUは商品一覧を見ながら考えていました。
洗剤、ゴミ袋、手袋、ペーパータオル……。
商品が増えてきました。
KAZUは、最初こう書こうとしました。
console.log("洗剤");
console.log("ゴミ袋");
console.log("手袋");3個なら書けます。
でも、100個なら100行です。
そこで、商品を一つの一覧にまとめます。
const 商品 = ["洗剤", "ゴミ袋", "手袋"];そして、順番に取り出します。
for (const 名前 of 商品) {
console.log(名前);
}JavaScriptくんは、洗剤、ゴミ袋、手袋と順番に処理します。
商品が10個になっても100個になっても、同じ仕組みで進められます。
プログラムの強みの一つは、同じ手順を何度でも繰り返せることです。
人は100回同じ確認をすると疲れます。
JavaScriptくんは、100回でも1000回でも、同じ指示なら同じように実行します。
第5回の第一歩：同じ形の処理を何度も書き始めたら、「繰り返しにできないか」を考える。
JavaScript講座・全10回 / 第5回 / 2ページ目（全3ページ）
掲載日：2026年9月13日
次は、商品の金額を合計します。
const 金額一覧 = [300, 500, 200];
let 合計 = 0;
for (const 金額 of 金額一覧) {
合計 = 合計 + 金額;
}正しい合計は1000円です。
ところが、ある日、KAZUが作った計算では結果が合いません。
そこで、JavaScriptくんに途中経過を報告してもらいます。
for (const 金額 of 金額一覧) {
合計 = 合計 + 金額;
console.log("途中の合計", 合計);
}表示は、
と進みます。
もし2回目で急におかしくなれば、その周辺を調べればよいと分かります。
これは、デバッグの基本的な考え方です。
「最終結果が違う」だけでは、原因の場所が分かりません。
途中の値を見えるようにすると、どこまでは正しく、どこからおかしいかを絞り込めます。
確認のコツ：結果が違ったら、途中の値を表示して「どこから違うか」を探す。
JavaScript講座・全10回 / 第5回 / 3ページ目（全3ページ）
掲載日：2026年9月13日
JavaScriptくんは、繰り返し処理が得意です。
でも、その便利さには注意も必要です。
もし条件を間違えたまま100件を処理すれば、100件まとめて間違えます。
KAZUは、発注が必要な商品だけを出す処理を作ります。
for (const 商品 of 商品一覧) {
if (商品.在庫 <= 商品.最低在庫) {
console.log(商品.名前 + "：発注");
}
}ここでは、商品を1件ずつ取り出し、その商品の在庫と最低在庫を比較しています。
正しければ、とても便利です。
でも、もし比較記号を逆に書けば、在庫が十分ある商品ばかり発注対象にするかもしれません。
いきなり100件の本番データで試すより、まず3件だけ用意します。
| 商品 | 在庫 | 最低在庫 | 期待 |
|---|---|---|---|
| 洗剤 | 1 | 2 | 発注 |
| 手袋 | 5 | 2 | 発注不要 |
| ゴミ袋 | 2 | 2 | 発注 |
これなら、
を一度に確認できます。
JavaScriptくんの得意なところと、怖いところが同じ場所にあります。
速く、何度でも、同じ処理をする。
正しい指示なら強力です。
間違った指示でも、やはり高速です。
第5回まとめ：繰り返しは、大量の同じ作業を任せる仕組み。小さいデータで確認し、条件と途中経過を見てから件数を増やす。
ここまでで、JavaScriptくんには「計算」「値の保持」「判断」「繰り返し」という仕事を任せられるようになりました。
少しずつ、単なるボタンの動きから「システムらしい処理」へ近づいてきました。
編集後記は、過去の内容を消さず、1回ごとに別ページとして残していきます。
KAZU × AI 編集後記
私はプログラマーではありません。介護の仕事をしながら、「仕事の中の面倒な作業を、もっと簡単にできないだろうか」と考えたことが、プログラミングに興味を持つきっかけでした。
システムを試作していくうちに、プログラムを作ること自体が面白くなってきました。そこで思いついたのが、初心者がゼロから一緒に学べるホームページです。
完成した教材だけを並べるのではありません。私自身が分からないところから始め、AIに質問し、実際に作り、失敗し、直していく。その過程まで記事にしてしまおうと考えました。
ホームページの骨格。
服装や見た目。
動作や判断。
この3つの役割を知ったことで、「ホームページは一つの言語だけで作るわけではない」ということが少しずつ見えてきました。
最初の試作では、見た目はホームページらしくなりました。しかし実際に触ってみると、画面はあるのにボタンや機能が十分に動きませんでした。
ここで初めて、「見た目ができること」と「システムとして動くこと」は別だと実感しました。そこでJavaScriptを使い、記事画面の切替、ボタン、ミニテスト、学習進捗、用語検索などを実際に動かすようにしました。
日本だけでなく海外の初心者にも読んでもらえる可能性を考え、言語切替を付けることにしました。最初は日本語と英語から始めました。しかし、ここでも簡単にはいきませんでした。
言語を選んでも表示が変わらない。調べると、古い翻訳処理と新しい翻訳処理を重ねて追加したことで、JavaScriptの定義が重複し、処理全体が止まる原因になっていました。
翻訳部分だけを継ぎ足して直すのではなく、一度整理して一つの仕組みにまとめ直しました。すると言語切替が動くようになりました。不具合が出たとき、目の前だけ直すより、構造自体を整理した方がよい場合があることを学びました。
現在の試作では、日本語、英語、フランス語、スウェーデン語、中国語、韓国語、ミャンマー語、インドネシア語、タイ語を選べる形にしています。
すると次は、メニューや見出しは切り替わるのに、一部だけ日本語が残る問題が出ました。表示されている文章の中に、翻訳データへ登録していないものがあったためです。そこで画面の文章を見直し、翻訳対象をまとめて管理する方向へ修正しました。
大学では経営情報を学び、コンピューターや情報処理についても一通り勉強しました。ただ、その頃は、学んだことを自分の生活や仕事に取り入れようとは、あまり考えていませんでした。勉強したことと、毎日の暮らしや仕事が、自分の中ではまだつながっていなかったのだと思います。
介護の仕事を続ける中で、入力や確認、集計など、「もう少し簡単にできないだろうか」と感じる場面が出てきました。消耗品の在庫を確認して発注につなげること。献立から必要な材料をまとめ、買い出しに使える形にすること。作りたいものが、仕事の中から具体的に見えてきました。
そこで初めて、大学で学んだことを、自分のためにも仕事のためにも使ってみようと思うようになりました。昔の知識をそのまま取り出せば、すぐに作れるというわけではありません。それでも、以前の学びを、今の経験と結びつけながら確かめ直すことはできます。
50代になった今、昔まいた種がようやく芽を出したような感覚があります。使っていなかった知識を掘り起こし、今の自分の経験と結びつけて、もう一度ゼロ地点から形にしていく。それが、今の自分にとっての「ゼロから始めるプログラム言語」なのだと思います。
実際にプログラムを作り始めて、一番最初に感じたのは、「思っていたプログラミングとは少し違う」ということでした。難しい言葉やコードを覚えることだけでなく、まず「どうしたいのか」を考えることが必要でした。
「ここをこうしたい」「このボタンがあった方が使いやすい」「入力するより選べた方が簡単ではないか」「一度入力したものを別の画面にも反映できないか」。普段の仕事で感じていた小さな不便が、プログラムを作る材料になりました。
もちろん、画面ができたからといって、すぐに思いどおりに使えるわけではありませんでした。ボタンを押しても動かない。入力した内容が別の画面に出ない。表示や印刷の形が思っていたものと違う。実際に使って初めて気づくことが、いくつもありました。
一つずつ動かし、どこがおかしいのかを確かめ、直して、もう一度使ってみる。直ったときには「あ、本当に動いた」と感じます。思っていたことが目の前で形になるところに、面白さがありました。
プログラムを作り始めてから、少しずつ自分の強みに気づくようになりました。仕事の中で、どこが面倒なのか、どの確認に手間がかかるのか、どんな表示なら使いやすいのか。そうしたことを、自分の経験から具体的に考えられることです。
見た目が整っていても、必要な内容が反映されなければ困ります。ボタンがあっても動かなければ使えません。自分が使う場面を思い浮かべるからこそ、「ここは変だ」「ここを直したい」と伝えることができます。
分からない技術は、AIに聞きながら確かめています。一方で、何を作りたいか、どこを直したいか、使ってみてどう感じたかは、自分の側から伝えなければなりません。経験を言葉にし、実際の画面で確かめる。その役割を、少しずつ意識するようになりました。
大学時代、僕はコンピュータや経営情報について一通り勉強しました。その当時は、授業として必要なことを学んでいるという感覚が強く、それを自分の生活や仕事に取り入れようとは、あまり考えていませんでした。
今は、先に生活や仕事の課題があります。「この作業を少し簡単にしたい」「必要な情報を分かりやすく見たい」。そのために何が必要なのかを調べ、試しています。学ぶ理由が、自分の日常の中にできました。
大学での学びと、仕事で積み重ねた経験。そして、分からないことを聞きながら形にしていけるAIとのやり取り。それぞれが、今になってつながり始めています。
一回の作業は、「技術面を3項目」「構成を3項目」「僕のことを3項目」。番号を振って、少しずつ進める方針にしました。技術の話だけに偏らず、ページの構成と、その中で何を伝えるかも一緒に考えていきます。
原則として毎日1時間ずつ作業し、2026年10月11日ごろの公開を目指します。技術を一度に大きく変えすぎると、自分でも分からなくなってしまいそうです。今あるものを動かして確認しながら、必要なところを足していきたいと思っています。
プログラムの型も大切ですが、中に何を載せるのかが肝心です。僕が何を考え、どう学び、仕事や生活でどう使おうとしているのか。その内容を、一つずつ積み重ねていきたいと思います。
2026年9月11日現在、サイトは基本構造を作る第1段階の終盤から、全体を仕上げる第2段階の入口にいます。記事、画面移動、動くボタン、進捗保存、ミニテスト、用語集、ヘルプ、スマホ表示、9言語対応の土台まで作ってきました。
まだ完成ではありません。記事追加、翻訳確認、連絡手段、プライバシーポリシー、SEO、公開環境でのテストなどが残っています。
目標は2026年10月11日前後にv1.0を公開することです。仕事をしながら少しずつ進めるからこそ、専門家ではない人間がAIと一緒にどこまで作れるのか、その過程自体を残していきたいと思っています。
KAZU × AI 編集後記
ホームページを作っているうちに、「インターネット上に家を建てるようなものだ」という感覚が強くなってきました。
最初は、一軒の小さな家でいい。記事が一つ増えれば、そこにもう一つ部屋ができる。別のテーマが増えれば、隣にもう一軒建つ。そうやって少しずつ広げていけば、やがて一つの町のようになっていくのかもしれません。
今あるのは、まず「学ぶ場所」です。記事を読み、用語を確認し、実際にコードを触る。
その次には、「作る場所」ができます。実際に作ったプログラムや、試作品、失敗から直した過程を置く工房です。
そして12月の課題として、「画廊」を作りたいと思っています。完成した画面だけではなく、最初の案、修正途中、完成版まで並べれば、作品そのものと制作の過程の両方を見せられます。
さらに先には、Facebookのように人同士が交流できる構造も考えられます。ただし、最初から大きなSNSを作る必要はありません。
学習記録を投稿する。作品を画廊に載せる。ほかの人がコメントする。まずは、このサイトに必要な機能だけを持つ小さな交流広場から始めればいい。
9月から10月は本体サイトを作り、公開まで持っていく。11月は、記事や導線を整える。12月は画廊。2027年に入ったら、小さな交流機能を試す。
一気に完成させるのではなく、一つ完成させてから次へ進む。建物を一軒ずつ増やすように進めれば、途中の成果も残ります。
サイトが育てば、広告、教材、テンプレート、小規模なツールなど、収益化につなげることもできます。ただし、先にお金だけを目的にするのではなく、まず人が読みたくなる内容と、実際に役立つものを蓄積することが大切だと思っています。
今はまだ町の入口です。まず一軒目をしっかり建てる。そして、次の一軒を増やす。その積み重ねを続けていきます。
JavaScript講座・全10回 / 第1回 / 1ページ目（全3ページ）
掲載日：2026年9月12日
ある日、数人さんの職場に、新しい助手がやってきました。
名前は「JavaScriptくん」。
この助手、とにかく計算が速い。商品が100個あっても、同じ手順の計算を延々と続けられます。
ただし、仕事を頼むにはコツがあります。
数人さんが言いました。
「洗剤、そろそろ少ないから、いい感じにしておいて」
JavaScriptくんは動きません。
さぼっているのでしょうか。
いいえ。「そろそろ」「少ない」「いい感じ」の具体的な意味が、プログラムに書かれていないからです。
そこで、指示を変えます。
「洗剤の在庫が2本以下だったら、画面に『発注してください』と表示して」
これなら、動く仕組みを作れます。
const 在庫 = 1;
if (在庫 <= 2) {
alert("洗剤を発注してください");
}今は記号を覚えなくても大丈夫です。書いてあることは、次の3つです。
プログラミングの第一歩は、曖昧なお願いを、実行できる手順に変えることです。
これは、職場の引き継ぎにも似ています。
「いつものようにお願いします」では、初めて担当する人には伝わりません。
「食事が終わったら食器を下げて、テーブルを拭いてください」なら、行動に移しやすくなります。
数人さんが発注システムについて決めた、
「最低在庫数に達したら、発注が必要と分かるようにする」
というルール。それは、まさにプログラムに必要な指示です。
コードを書き始める前から、設計は始まっています。
ただし、JavaScriptくんには棚を見る目はありません。
棚から洗剤を1本使っても、それだけでは画面の数字は変わりません。人が使用数を入力するなど、現実の変化を伝える仕組みが必要です。
計算を任せることと、現実の情報を集めることは、別々の仕事なのです。
JavaScript講座・全10回 / 第1回 / 2ページ目（全3ページ）
掲載日：2026年9月12日
今度は、発注画面を一つ作ることにします。
登場するのは、3人の担当者です。
| 担当者 | 主な仕事 | 発注画面では |
|---|---|---|
| HTMLさん | 部品を用意する | 商品名・入力欄・ボタンを置く |
| CSSさん | 見た目を整える | 色・文字の大きさ・配置を調整する |
| JavaScriptくん | 動作を受け持つ | 計算して、結果を表示する |
HTMLさんが「発注する」というボタンを置きました。
CSSさんが、ボタンを見やすい緑色にしました。
立派な画面になりました。
ところが、押しても発注処理が始まりません。
そこでJavaScriptくんの出番です。
「このボタンが押されたら、この処理をする」という指示をつなぎます。
まずは、押すと文字が変わる小さな例を見てみましょう。
<button onclick="返事する()">呼び出す</button>
<p id="伝言">待機中です</p>
<script>
function 返事する() {
document.getElementById("伝言").textContent =
"はい、何を計算しましょう？";
}
</script>画面には、最初に次のものが出ます。
「呼び出す」ボタンと、「待機中です」という文字です。
ボタンを押すと、文字が変わります。
はい、何を計算しましょう？
このとき、裏側では3つのことが起きています。
functionは、ひとまとまりの仕事に名前を付けるための書き方です。
ここでは、その仕事を「返事する」と名付けました。
id="伝言"は、画面の部品に付けた目印です。
職場で「そこの書類を取って」と言われても、書類が何枚もあれば迷いますよね。
「発注書と書かれたファイルを取って」なら、探す対象が分かります。
JavaScriptも同じです。画面のどの場所を変えるか、目印を使って指定できます。
ここまで分かると、以前の「ボタンが反応しない」という問題の見方が変わります。
見た目が完成していても、呼び出す処理の名前が違っていたり、途中でエラーが起きていたりすると、目的の動作にはつながりません。
画面があることと、仕事の流れがつながっていることは、それぞれ確認が必要です。
JavaScript講座・全10回 / 第1回 / 3ページ目（全3ページ）
掲載日：2026年9月12日
では、JavaScriptくんに発注の判断を一つ任せましょう。
今回は、次のルールです。
洗剤の在庫が2本以下なら、「発注が必要です」。3本以上なら、「在庫は足りています」。
コードにすると、こうなります。
const 在庫 = 1;
const 最低在庫 = 2;
if (在庫 <= 最低在庫) {
alert("発注が必要です");
} else {
alert("在庫は足りています");
}急に難しそうに見えるかもしれませんが、順番に読むと単純です。
const 在庫 = 1;「在庫」という名前を付けて、数字の1を扱います。
こうして情報に名前を付けると、数字だけを並べるより意味が分かりやすくなります。こうした名前付きの情報を扱う仕組みが「変数」です。なお、constで作った名前には、後から別の値を代入できません。
if (在庫 <= 最低在庫)「もし、在庫が最低在庫以下なら」という意味です。
<=は「以下」。今回なら、2本ちょうども含みます。
else「そうでなければ」という意味です。
今回は、在庫が2本以下ではない場合に「在庫は足りています」と表示します。
これで、在庫数によって返事が変わるようになりました。
動作を確かめてみましょう。
| 入れた在庫数 | 出てほしい結果 |
|---|---|
| 0本 | 発注が必要です |
| 1本 | 発注が必要です |
| 2本 | 発注が必要です |
| 3本 | 在庫は足りています |
| 10本 | 在庫は足りています |
ここで、数人さんがわざと記号を変えたとします。
if (在庫 >= 最低在庫)>=は「以上」です。
すると、10本あるのに「発注が必要です」と言い、0本なのに「在庫は足りています」と言ってしまいます。
JavaScriptくんは、胸を張って報告します。
「指示どおりに実行しました！」
たしかに、書かれた指示には従っています。でも、頼みたかった仕事とは逆です。
これが、動いてはいるけれど、結果が間違っている不具合です。
だから確認するときは、「何か表示された」で終わりにせず、「この数字なら、この結果になるはず」と比べます。
特に今回は、境目の2本と3本を確かめると、ルールの間違いを見つけやすくなります。
なお、この例は学習用です。本物の入力画面では、空欄やマイナスの数字が入った場合も考えます。それは、基本の動きを理解してから追加していきましょう。
今日の持ち帰りは、3つです。
次回は、この助手に「商品名」「単価」「数量」を渡します。
いよいよJavaScriptくん、電卓係に就任です。
KAZU × AI 編集後記
Cloudflareで最初の公開に成功したとき、KAZUは画面を見ながら、しばらくそのURLを眺めていました。
それまでのホームページは、自分の端末の中にあるファイルでした。
HTMLを直し、CSSを整え、JavaScriptを動かす。何度も失敗しながら、少しずつ形にしてきました。
でも、その日から意味が変わりました。
「自分の中だけの作品」から、「外から見られるサイト」になった。
公開できたのだから、あとは記事を増やしていけばいい。
KAZUはそう思っていました。
しかし、実際にはそう簡単ではありませんでした。
新しいファイルを作ったのに、公開ページは古いまま。
どのファイルをアップロードしたのか。
最新版はどれなのか。
Cloudflareのどの画面から更新するのか。
公開前とは違う種類の迷いが増えていきました。
ここで初めて、ホームページには二つの仕事があると気づきました。
一つは、ページそのものを作る仕事。
もう一つは、作ったものを公開し、更新し、壊れていないか確認する仕事です。
そこで、動いていた版を消さずに残すことにしました。
v0.67、v0.68、v0.84……。
最新版を作るたびに、前の成功版を保存する。
公開するときだけ、最新版を index.html として使う。
このルールができてから、更新の怖さが少し減りました。
もし新しい版で失敗しても、戻れる場所があります。
さらに、記事を増やすときにも問題が出ました。
同じ内容を追加し直せば、記事が重複する。
新しい編集後記を上書きすれば、過去の記録が消える。
機能を直したつもりが、別の機能を壊すこともある。
そこで、KAZUは更新のたびに確認することを決めました。
前の内容が残っているか。重複していないか。新しい内容だけが増えているか。
公開した日が完成日ではありませんでした。
むしろ、その日からサイトは「育てるもの」になりました。
KAZU × AI 編集後記
最初のころ、KAZUは画面が動くたびにうれしくなりました。
ボタンを押すと画面が変わる。
用語を検索できる。
翻訳ボタンが動く。
ミニテストが進む。
ところが、ある日、記事一覧を見ていて気づきました。
機能は増えていました。
でも、読む記事が少ない。
用語集も、検索機能があっても中身が少なければ意味がありません。
翻訳機能があっても、翻訳する文章そのものが少なければ広がりません。
ここで、KAZUは一つ大きなことに気づきました。
プログラムは器であって、サイトの価値そのものではない。
用語集なら、検索機能と237語の中身がそろって初めて役に立つ。
ミニテストなら、ボタンが動くだけではなく、問題・ヒント・理由があって学習になります。
JavaScript講座も、コードだけを並べるのではなく、なぜそれを使うのか、どこで失敗するのか、どう直したのかまで書くことで、初心者が読み続けやすくなります。
ここで、さらに面白いことに気づきました。
今まで困ったことの多くが、そのまま教材になります。
翻訳が動かなかった。
用語検索が反応しなかった。
Cloudflareでどこを押すか分からなかった。
公開したのに反映されなかった。
サイトマップが最初は取得できなかった。
そのときは「失敗」でした。
でも、順番に整理すれば、初心者が同じところで迷ったときの案内になります。
このサイトの強みは、専門家が完成した知識だけを教える形ではありません。
KAZU自身が、分からないところから始めています。
だから、
「ここが分からなかった」
「ここで間違えた」
「こうしたら直った」
という過程を、そのまま残せます。
この頃から、KAZUの中でサイトの作り方が少し変わりました。
新しい機能を一つ追加するだけでなく、記事を一つ増やす。
新しい用語を足す。
編集後記で制作の裏側を残す。
技術と内容を、一緒に育てる。
KAZU × AI 編集後記
最初にHTMLを触り始めたころ、KAZUはまだ自分がここまで来るとは思っていませんでした。
ホームページの骨組みがHTML。
見た目を整えるのがCSS。
動きを付けるのがJavaScript。
一つずつ聞きながら、確かめながら進めていました。
そんな気持ちが出ることもありました。
学校では、今の若い世代が普通にプログラミングを学ぶ時代です。
「自分はずいぶん遅れて始めたんだな」と感じる瞬間もありました。
KAZUには、ただ勉強するだけではなく、作りたいものがありました。
仕事で使える発注システム。
献立から材料を拾い出す食材システム。
そして、初心者が一緒に学べるホームページ。
先に課題があったから、学ぶ理由がはっきりしていました。
大学では経営情報を学び、コンピューターや情報処理にも触れていました。
でも、その頃は、学んだことを自分の生活や仕事に取り入れるという発想は強くありませんでした。
知識は知識。
仕事は仕事。
別々に存在していました。
それが50代になった今、つながり始めました。
もちろん、順調だったわけではありません。
ボタンが動かない。
翻訳されない。
最新版がどれか分からない。
Cloudflareの画面で迷う。
サイトマップがうまく読まれない。
何度も「どこ？」「なぜ？」と止まりました。
でも、そのたびに画面を確認し、やり直し、少しずつ前へ進みました。
完璧に理解してから進んだのではありません。
進みながら理解した。
そして、Cloudflareで公開されたページを実際に開いたとき。
そのとき、学習が「勉強」だけではなくなりました。
自分で作ったものを、インターネット上に置いた。
その経験が残りました。
若いときに資格を取れば、良い環境に入りやすいかもしれません。
でも、年齢を重ねてからでも、実際に作り、公開し、直し続けることはできます。
大事なのは、一度に全部覚えることではありません。
分からないところを一つずつ潰していく。
毎日少しずつ積み重ねる。
そして、実際に動くものを残す。
コードは、年齢を見ません。
正しければ動く。
間違っていれば動かない。
その厳しさと分かりやすさが、今は面白く感じられます。
KAZU × AI 編集後記
その日の朝、KAZUの手元にあったのは、一つの index.html でした。
見た目も整ってきた。
記事もある。
用語集も動く。
翻訳も付けた。
でも、まだそれは自分の端末の中にあるだけでした。
ここから、「ホームページを作る」作業が、「ホームページを公開する」作業へ変わりました。
最初に迷ったのは、どのファイルを公開するのかでした。
制作途中の版はいくつもあります。
v0.67、v0.68、v0.84……。
そこで、過去版は版名付きで保存し、公開用だけ index.html にすることにしました。
このルールが、後の更新でも基準になりました。
Cloudflareの管理画面を開きます。
Workers & Pages。
そして、zero-kara-prog。
ところが、画面にはたくさんの項目があります。
概要。
デプロイ。
設定。
ドメイン。
どれも、それらしく見えます。
何度か画面を行き来しながら、ようやく「公開したサイトを更新する場所」が見えてきました。
更新しようとしていると、「アプリケーションを作成する」という画面も出てきます。
一瞬、KAZUは考えました。
既存の zero-kara-prog を開く。
そして、
「デプロイ」→「新しいデプロイ」
へ進む。
これが、更新の入口でした。
最新版のindex.htmlを選び、デプロイします。
しばらく待つと、更新が完了します。
でも、ここで終わりではありません。
公開URLを開いて、本当に新しくなったか確認します。
ここで初めて、「デプロイ成功」と「公開ページが正しい」がつながりました。
途中で、「有効なURLがありません」と見える場面もありました。
ファイルは置いたのに、外から見る住所が有効になっていない。
そこで設定のドメイン画面を開き、プロダクションの
zero-kara-prog.mmdei.workers.dev
を有効にしました。
まさに、そんな感覚でした。
公開できたあと、次に考えたのは検索です。
URLを知っている人だけが来るのではなく、Googleにも見つけてもらいたい。
そこで、robots.txt と sitemap.xml を用意しました。
sitemap.xmlをブラウザで開くと、見慣れない英語が表示されます。
「壊れているように見えるもの」が、実は正常。
ここでも、実際に確認しながら一つ覚えました。
Google Search Consoleへサイトマップを送信します。
ところが、最初はうまくいきません。
「取得できませんでした」
そこで、まずsitemap.xmlが直接開けるかを確認しました。
URLから読める。
公開されている。
そのうえで、もう一度送信します。
そして、画面に出た表示は、
「成功しました」
ただの設定画面なのに、その文字が少しうれしく見えました。
次はURL検査です。
トップページのURLを入れます。
しばらく待つと、表示されたのは、
「URL は Google に登録されています」
さらにCloudflareの解析には、GoogleBotのアクセスも見えました。
ここで、インターネット公開が急に現実味を持ちました。
ページを作った。
URLで公開した。
Googleへ知らせた。
そして、Googleが見に来た。
KAZUは、この流れを家づくりにたとえました。
HTMLで家を建てる。
Cloudflareの土地へ置く。
workers.devで住所を付ける。
sitemap.xmlで案内図を作る。
Search ConsoleでGoogleへ知らせる。
最初は「インターネットにつなぐ」という一言しか分かりませんでした。
でも今は、どこを押し、何を置き、どこで確認するのかを順番で説明できます。
ただページを作っただけではありません。
自分の手元のファイルを、世界中からアクセスできる場所へ置くところまで進みました。
KAZU × AI 編集後記
サイトを作り始めたころは、著作権なんてほとんど考えていませんでした。
自分がやっているのは、HTMLを書いて、ボタンを付けて、用語集を作って、ミニテストを増やしているだけ。そんな大げさな話ではないと思っていました。
ところがある日、「翻訳機能って、著作権大丈夫なのかな？」という疑問が出てきます。
例えば、誰かが書いた文章を持ってきて英語にする。
日本語の本を英語にしたら突然持ち主が変わる。そんな魔法があったら出版社は大騒ぎです。
翻訳したから自由に使えるわけではない。ここまでは他人の権利の話でした。
ところが次の瞬間、逆の疑問が出てきます。
編集後記。教材。ミニテスト。用語集。自分で考えた説明。
「あれ？ これ、僕のじゃん」――今さらです。
それまで編集後記は「今日こんなことをやりました」という日記のような感覚でした。でも、文章を考え、言葉を選び、順番を考え、失敗した話まで残しています。
ミニテストも、問題を考え、選択肢を作り、解説を書く。用語集も、難しい言葉をなるべく使わずに説明しようとすると意外に頭を使います。
サイトの中には、少しずつ自分が作ったものが増えていました。
ここで少し調子に乗りかけます。
残念。そんなに甘くありません。
「初心者向けのプログラミングサイトを作る」という発想自体は、誰か一人だけのものにはしにくい。
でも、どう説明するか、どんな文章にするか、どんな図や物語にするか。そこには、その人らしさが出ます。
料理で言えば、「カレーを作る」はみんなできる。でも「自分のレシピや文章まで、そのまま持っていくな」という話です。
文章やイラストの話をしていたら、今度は「名前はどうなる？」という疑問が出てきました。
ここで登場したのが商標です。
家に例えるなら、著作権は家の中に置いた本や絵。商標は玄関の看板。
自分にも独自のブランドがあります。具体的な名称はここでは伏せますが、今後、教材やシステム、別のサービスを同じ看板の下へまとめることも考えられます。
さらに奥の部屋には「特許」がいました。
自動で情報を集める。締切を管理する。エラーを見つける。直し方まで判断する。そうした仕組みが本当に新しい技術として形になれば、特許という世界が関係してくる可能性があります。
もちろん「自動で直ったら便利だよね」だけでは足りません。どう動き、何を見て、どう判断するのかまで具体的にする必要があります。
ある日ネットを見たら、自分の文章、自分のミニテスト、自分の編集後記とよく似たものが別のサイトに並んでいる。
これは嫌です。たぶん最初に「おい」と言います。次に「ちょっと待て」。そのあと「それ僕のやつだろ」です。
だから、いつ作ったか、どのバージョンだったか、どう変更してきたかを残しておくことにも意味があります。
今まで続けてきたバージョン管理や編集後記は、思い出だけでなく「どう作ってきたかの記録」にもなるのです。
作る。公開する。育てる。守る。そして、できれば盗まれない。
プログラムを勉強していたはずなのに、気づけば法律の話までしています。でも、世界へ公開するということは、自分の作品を外へ置くということでもあります。
サイト作りは、まだまだ奥が深い。
KAZU × AI 編集後記
サイトを見ている人には、完成した画面しか見えません。記事がある。ボタンがある。用語集がある。ミニテストがある。
そこへたどり着くまで、裏ではかなりバタバタしています。
記事を一つ作るだけでも、何を書くか決める。資料を集める。書く。直す。もう一回読む。公開日を決める。公開する。終わったと思ったら次の記事が待っています。
そこで一番危険な言葉が出てきます。
便利な言葉です。何も決めなくていい。気持ちも楽です。そして、だいたいやりません。
9月20日までに原稿。22日に確認。24日に公開。こう決めると、急に逃げ道がなくなります。
締切というのは少し怖い。でも、かなり優秀です。
記事Aは20日。記事Bは22日。翻訳確認は23日。公開は24日。用語集更新は25日。
そこでプログラムの出番です。
登録しておけば、「締切まであと3日です」「まだ終わっていません」「今日は確認日です」「公開予定日になりました」と教えてくれます。
しかも文句を言わない。機嫌も悪くならない。淡々と「未完了です」と言ってくる。ある意味、人間より怖い。
昨日と同じ画面に見えても、裏では記事を書き、翻訳し、確認し、修正し、次の公開日を決め、古いデータを残し、次の作業を準備しています。
まるで舞台です。客席から見えるのは役者だけ。でも舞台裏では、衣装、照明、音響、大道具、時間管理、進行が走り回っています。
サイトも同じ。表だけ見れば静か。裏では大騒ぎです。
「いつまで？」と聞かれるのは、できれば避けたいものです。でも、自分でサイトを運営するようになると締切の意味が変わりました。
締切がないと終わらない。期日がないと公開されない。予定がないと次へ進まない。
しかも締切には、「はい、今日はここまで」と止めてくれる役目もあります。線がなければ、もっと直したい、もっと追加したいで、永遠に完成しません。
締切を見て知らせる。未完了を見つける。必要なデータを集める。確認待ちを並べる。公開日になったら準備する。終わったら履歴に残し、次の作業を作る。
ここまでできたら、サイトの中に小さな裏方チームがいるようなものです。
ただし、設定を間違えると全員そろって間違えます。そこは少し怖い。
最初は画面を作ることしか考えていませんでした。今は「どうやって毎週動かし続けるか」まで考えています。
作る。締切を決める。進み具合を見る。記録を残す。公開する。次の仕事を用意する。
これが裏方の仕事です。
家で言えば、壁の中の配線や水道。普段は見えない。でも止まったら大騒ぎ。
どこまで行くのか、自分でも少し分からなくなってきました。でも、かなり面白い。
KAZU × AI 編集後記
ある日、サイトを眺めていて思いました。
記事、ミニテスト、用語集、翻訳、編集後記、LINE、プライバシーポリシー。最初は何もなかった部屋に、少しずつ家具を運び込んできたようなものです。
机。「お、いいじゃん」。椅子。「これも必要」。本棚。「これは絶対いる」。テレビ。「せっかくだから」。観葉植物。「ちょっとオシャレかな」。
サイトも同じでした。機能を増やすのは楽しい。でも、見る人が「記事を読みたい」と思ったとき、どこを押せばいいか分からなければ困ります。
必要なものを、必要な場所に置く。よく使うものは前へ。たまに使うものは少し奥へ。全部を主役にすると、誰も主役に見えません。
家でもサイトでも、「何を置くか」より「何を置かないか」のほうが難しい。
家具屋で気に入ったものを全部買ったら、たぶん家には入りません。機能も、置けばいいというものではありません。
KAZU × AI 編集後記
次に気になったのがボタンでした。
記事、用語集、編集後記、翻訳、LINE、戻る、次へ。いろいろあります。
作った本人には分かります。でも初めて来た人には分かりません。
自分の家に友達を呼んで、「トイレどこ？」と聞かれ、「分かるでしょ」と言っているようなものです。分かるわけがありません。
トイレ、玄関、押し入れ、風呂場。全部同じドアで、全部に「開けてみてください」としか書いてなかったら、かなり困ります。
サイトも「詳しく見る」「こちら」「開く」ばかりでは、どこへ行くか分かりません。
「ミニテストを始める」「用語を調べる」「編集後記を読む」と書いてあったほうが安心です。
重要なボタンは少し目立たせる。戻るボタンは控えめにする。押す前に何が起こるか分かる。それが大事でした。
KAZU × AI 編集後記
パソコンで見ると、サイトはけっこう広い。ボタンも並ぶ。文章もゆったり読めます。
ところがiPhoneで開く。急に部屋が狭くなります。
記事、進捗、ミニテスト、用語集、困ったとき、プロフィール、年間計画、編集後記……。まるでワンルームへ家具を全部持ち込んだ感じです。
パソコン版をそのまま小さくすればいいわけではありません。
文字は小さすぎないか。指で押せる大きさか。ボタン同士が近すぎないか。一番よく使うものが上にあるか。スクロールして迷子にならないか。
「動けばOK」では足りません。使っていて疲れないか。ここまで考えて、ようやくインテリアになります。
サイトのインテリアは一度完成して終わりではありません。記事が増えれば配置も変わる。機能が増えれば整理も必要です。
家だって住み始めてから家具を動かします。サイトも、作って、使って、「あれ？」と思ったら直す。その繰り返しでいい。
豪華じゃなくてもいい。迷わない。疲れない。ちょっと居心地がいい。そんなサイトにしていきたいと思います。
KAZU × AI 編集後記
画面を開いた。最初に出た言葉は、これでした。
HTMLはある。文章もある。ボタンも消えていない。それなのに、どう見てもおかしい。
文字の間隔が妙に広い。カードの位置が落ち着かない。さっき直したはずの場所が、別の画面ではまた崩れている。
ホームページというのは不思議です。完全に壊れているなら、いっそ全部消えてくれた方が分かりやすい。ところがCSSの崩れは、そうはいきません。
一見すると動いている。でも、どこか変です。人間でいえば、普通に歩いているように見えるのに、靴を左右逆に履いているようなものです。
今回のサイトも、まさにそんな状態でした。
HTMLの骨組みは生きている。問題は、その上に着せていたCSSでした。
この時点ではまだ知りませんでした。画面の裏側で、昔のCSSと新しいCSSが、静かに席の取り合いを始めていたことを。
KAZU × AI 編集後記
原因を追い始めると、少しずつ事情が見えてきました。
そこへ最後の大物が登場します。
会議終了。……と思ったら、別の場所にも !important がいました。
最優先が二人いる。もう最優先ではありません。
こちらから見えるのは、その会議の結果だけです。文字が重なる。余白が広がる。カードが変な位置へ行く。ボタンが妙に小さくなる。
ここで一つ分かりました。CSSは、足せば足すほど良くなるわけではありません。良かれと思って追加したものが、あとから邪魔になることがあります。
HTMLが家の骨組みなら、CSSは内装。けれど実際には、壁紙でもあり、照明でもあり、家具でもあり、廊下の幅でもありました。
家具を置きすぎれば歩けません。今回のサイトも、少しそれに近かったのです。
KAZU × AI 編集後記
そこで方針を変えました。
さらに飾るのをやめる。まず、読めるようにする。
PCの本文幅を整える。文字を少し大きくする。行間を広げる。会話欄を見やすくする。カードの高さを無理にそろえない。そして、iPhone側はなるべく触らない。
つまり今回は、デザイン工事というより整理整頓でした。
一つ直す。画面を見る。また直す。もう一度見る。
そして、ようやく画面が戻りました。
短い言葉でした。でも、今日いちばんうれしい言葉でもありました。
今回学んだのは、CSSの書き方だけではありません。
見た目を良くすることと、見やすくすることは同じではない。
飾ることより、読めること。増やすことより、整理すること。
CSSに勝つ必要はありません。CSSと喧嘩しない作り方を覚えればいい。
KAZU × AI 編集後記
HTMLで骨組みを作りました。CSSで内装を整えました。JavaScriptで電気を通しました。
……と思いました。
でも、誰も見に来ません。当たり前でした。家はできている。でも、その家はまだ自分の端末の中にあります。
住所がない。道路もない。
そこで登場したのがCloudflareでした。
最初は名前からして少し強そうでした。Cloud。Flare。なんとなく空から何か降ってきそうな名前です。
でも、実際に使うと役割は分かりやすい。
自分で作った家を、インターネットという街へ持っていき、住所を付けて、人が見に来られるようにする。
index.html を置く。デプロイする。URLを開く。
さっきまで自分の端末の中にしかなかったページが、世界から見られる場所に立っています。
ただし、引っ越して終わりではありませんでした。公開した瞬間から、今度は改修工事が始まりました。
KAZU × AI 編集後記
公開して、直して、確認して。また直す。
文字が重なる。戻るボタンがない。CSSがけんかする。古い指定が残っている。PCとiPhoneで挙動が違う。
そのうち、当然こう思いました。
例えばJavaScriptにページ内を見回らせる。「戻るボタンがない」「同じ要素が重複している」といった問題を確認させる。
Pythonには裏方を任せる。HTMLファイルを読み、同じ修正を複数箇所へ入れたり、決まったパターンをまとめて点検したりする。
CSSは現場の内装担当。HTMLは構造担当。JavaScriptはページの動作担当。Pythonは裏側の作業員。
つまり、「自動修正言語」という一つの魔法の言語があるわけではありません。
複数の言語を組み合わせて、自動修理班を作る。
考えてみれば、ホームページを作っていたはずなのに、気づけば修理会社まで作ろうとしていました。
KAZU × AI 編集後記
「だったら全部自動で直せばいい。」
そう思うと、急に夢が広がります。
でも、自動修正には怖いところがあります。
ロボットに「この部屋、狭いから広くして」と言ったら、壁まで壊すかもしれません。
「ボタンを見やすくして」と言ったら、全部のボタンを巨大化するかもしれません。
これを伝えなければ、PCを直したつもりがiPhoneまで別物になる可能性があります。
実際、今回も「直した」「直ってない」「そこじゃない」を何度か繰り返しました。
ここで大事なことが分かりました。
自動化で最初に必要なのは、プログラムではなく「正しい状態」を決めること。
PCはこう。iPhoneはこう。文字サイズはこれ。このボタンは残す。このページには戻るボタンを付ける。
正解を決めて、その手順を記録し、それからプログラムに覚えさせる。
将来は、HTMLを保存すると自動点検が走り、安全な問題は自動修正し、危険な変更だけ人間が確認する。そして問題がなければCloudflareへ公開する。
そこまで行けば、ホームページの自動修理工場です。
KAZU × AI 編集後記
最初は、もっと簡単な話だと思っていました。
プログラミングのサイトだから、パソコン。コード。キーボード。まあ、その辺だろう。
でも、どうもしっくりきません。
そこで街の写真を見始めました。高い建物。霧の中の街。遠くまで続くビル。
上へ伸びている。遠くまで広がっている。プログラミングで世界が広がる感じにも見えます。
ただ、少し硬い。このままだと「初心者歓迎」というより、「できる人だけ入ってきてください」にも見えます。
それは違う。
そこで光を足した。緑を足した。花を足した。
気がつけば、プログラミングサイトを作っていたはずなのに、庭づくりが始まっていました。
KAZU × AI 編集後記
最初は街でした。
次に、そこへ太陽が出ました。その次に緑が増えました。さらに花が咲きました。
どんどん優しくなる。どんどん明るくなる。
街なのか。庭なのか。学習サイトなのか。旅行ポスターなのか。
だんだん分からなくなってきました。
でも、不思議と嫌ではありませんでした。むしろ、そっちの方が面白い。
プログラミングというと、黒い画面、英数字、難しそう、間違えると怖そう。そんな印象があります。
だったら逆に、花が咲いていてもいい。朝日が差していてもいい。パソコンの横にコーヒーがあってもいい。
コードを書く場所は、もっとやさしくてもいい。
その頃にはもう、「画像を選ぶ」という話ではありませんでした。
このサイトに、どんな空気を流すかを考えていたのです。
KAZU × AI 編集後記
候補の画像を並べてみると、それぞれの性格が見えてきました。
黄色や緑が強く、少し夢の中のようなものは、「始めよう！」と前から引っ張ってくる感じがします。
花と朝の光が自然につながるものは、少し静かです。でも、「まあ、座っていきなよ」と言ってくる感じがあります。
ここでようやく分かりました。
画像には性格がある。
同じサイトでも、画像一枚で先生にも見える。友達にも見える。会社にも、雑誌にも見える。
そして自分が本当に欲しかったのは、「すごいサイトに見せること」だけではありませんでした。
「ここなら自分でも始められそう」と思ってもらうこと。
最初は「ホームページの画像、何にしようかな」でした。
でも最後には、「このサイトは、どんな性格でありたいんだろう」という話になっていました。
画像を決めていたはずなのに、決めていたのはサイトの性格だったのです。
完璧な未来都市でもない。パソコンだけの部屋でもない。
街があり、花があり、光があり、その中に学ぶ場所がある景色。
少し不思議で、少しやさしくて、少し先へ行ってみたくなる。
最後に残ったのは「かっこいい画像」ではありませんでした。
「ここから始めてもいいかも」と思える景色。
それが、このホームページの顔になりそうです。
CONTACT
感想・ご質問・不具合のご報告など、こちらからお知らせください。
教材の内容、使い方、分かりにくいところなど。
翻訳・ボタン・表示など、おかしな動きを見つけたときに。
作品紹介、スポンサー・PR掲載などのご相談。
下のフォームからお問い合わせを送信できます。
送信内容はお問い合わせ対応のために利用します。送信前にプライバシーポリシーをご確認ください。
第3回・記載日：2026年9月12日
KAZU × AI 編集後記
2026年9月12日、Cloudflareでホームページを初めて公開できました。「ひと通り動きます」と伝えられたのは、一つの区切りでした。自分の手元で見ていたページが、インターネットから開けるようになったのです。
そこにたどり着くまでには、何度も画面を確認しました。どのファイルを使うのか。どのフォルダに入れるのか。管理画面のどこを押すのか。説明に出てくる言葉が分かっても、自分の画面のどこを指しているのか分からなければ、次へ進めません。
「手順を追って」「何をひらけば良いの？」。質問を重ねながら、一つずつ確かめました。初心者向けのページを作る自分自身が、案内の分かりやすさを試す立場にもなっていました。
公開できると、次は更新です。しかし、新しいファイルに替えるたびに前のものがなくなったら、うまく動いていた状態へ戻れません。そこで、初回公開に成功したv0.67を基準版として残すことにしました。
保管するファイルにはバージョン名を付け、公開に使うものはindex.htmlにする。中身を作るだけでなく、どれを使っているのか分かるように保管することも、制作の一部だと感じました。
インターネットで開けるようになっても、翻訳や用語集には確認が必要でした。翻訳されない文章がある。探したい言葉が少ない。ひらがなで検索しても出てこない。実際に使うと、まだ足りない部分が見えてきます。
「接続できたこと」と「読みたいものを読めること」は、それぞれ確かめる必要があります。これからは、読者が押すボタン、入力する言葉、読み進める順番を、自分でもたどって確認していきたいと思います。
編集後記についても、「雑になってるよ」と伝えました。ここに残したいのは、完成しましたという短い報告だけではありません。何を尋ね、どこで止まり、どう考えて次に進んだのか。その経緯があってこそ、自分の制作記録になります。
大学で学んだことが、仕事や生活の課題と今になってつながってきた。その出発点から続く記録を、更新のたびに薄くしたくありません。以前の記事を残し、新しい出来事は日付を付けた別の回として増やしていきます。
今日は、公開という一歩を進められました。同時に、使える内容に整える仕事も見えてきました。10月11日ごろの完成目標へ向け、次は一つひとつの使い心地を確かめていきます。
第4回・記載日：2026年9月12日
KAZU × AI 編集後記
どのコンピュータ言語から学べばいいのか。ホームページを作りながら、学ぶ順番も整理しました。名前を次々に覚えるより、今作っているもののどこで使うのかが分かる方が、先へ進みやすそうです。
HTMLで文章やボタンを置く。CSSで色や配置を整える。JavaScriptでボタンを押した後の動きや計算を作る。家づくりにたとえると、形を作り、見た目を整え、暮らすための仕組みを付けていくように考えられます。
今回のLINE画面にも、この考え方を使えます。文章とリンクを置き、追加ボタンを見やすくし、メニューから画面を開けるようにする。大きな機能も、小さな役割に分けると考えやすくなります。
その後は、Pythonでデータを扱う処理や自動化を学び、SQLで保存した情報を取り出す方法を学ぶ。そしてAPIで、ほかのサービスと情報をやり取りする仕組みへ進む方針にしました。APIは言語の名前ではなく、サービスをつなぐための窓口や約束です。
HTML → CSS → JavaScript → Python → SQL → API。この順番を、自分たちの「一軒目の家づくり」として進めます。すべてのホームページに全部が必要という意味ではなく、役割を順番に理解するための学習計画です。
TypeScript、Java、C#、Swiftなどについては、作りたいものに合わせて学ぶ「別の家づくり」と考えることにしました。今すぐ全部を覚えようとせず、一軒目でつかんだ考え方を、次の目的へつなげていきます。
ホームページにメールでやり取りできる画面があれば、という話もしました。一方で、ウイルスへの心配もあります。メール機能は後の課題にし、今回はLINEの友だち追加画面を付けることにしました。
スマートフォンならボタンから、パソコンなら表示されたQRコードから。読むだけだったページに、人とつながる入口を一つ加えます。その先でどう交流するかも、実際に使いながら考えていきたいと思います。
プログラムの型も大切だけれど、中身の内容が肝心。これからも、機能を増やすたびに「何のために付けるのか」「読む人に伝わるか」を確かめながら、一軒目の家を育てていきます。
第27回・記載日：2026年9月18日
KAZU × AI 編集後記・第二章
サイトが動いた。翻訳も動いた。お問い合わせも付いた。
「よし、完成に近づいた！」……と思ったら、次に出てきた言葉がセキュリティだった。
昨日まで「このボタン、もう少しピンクがいいな」などと言っていた人間が、今日はパスワード、アクセス制御、ログの話をしている。急に話が物騒である。
ホームページも家と同じらしい。建てれば終わりではない。玄関を付けたら鍵がいる。窓を作ったら戸締まりがいる。
サイト作りを始めたはずなのに、気がつけば私はインターネット上の戸締まり係になっていた。
第28回・記載日：2026年9月18日
KAZU × AI 編集後記・第二章
セキュリティを設定すると、秘密の番号が次々と登場する。
「これは大事だから保存しておこう」そこで初心者が思いつく最も簡単な方法。スクリーンショット。
……待て。秘密の番号を写真に撮って、いつでも見られる場所に置いたら、それは本当に秘密なのだろうか。
家の合鍵をなくさないように、玄関の横にぶら下げておくようなものである。便利と安全は、どうも仲が悪い。
この日覚えたこと。秘密は「覚えている」から秘密なのではない。「他人から見えない」から秘密なのである。
第29回・記載日：2026年9月18日
KAZU × AI 編集後記・第二章
セキュリティは地味だ。翻訳ボタンなら、押して英語になれば「おお！」となる。お問い合わせフォームなら、メールが届けば「来た！」となる。
ところがセキュリティは違う。何も起きない。
今日も何もない。明日も何もない。最初は「これ、本当に働いているの？」と思う。
でも考えてみれば、防犯装置が毎日大活躍する家には住みたくない。何も起きない日を作る。それがセキュリティの仕事だった。
今日も異常なし。地味だけど満点。
第30回・記載日：2026年9月18日
KAZU × AI 編集後記・第二章
そして現れた。GitHub。 名前からして強そうである。
さらに画面を開くと、Repository。Commit。Branch。英語が三人並んだ。 帰ろうかと思った。
ところが一つずつ調べてみると、やっていることは意外と普通だった。ファイルを置く。変更を記録する。前の状態を残しておく。
「それなら最初からそう言ってくれ！」
プログラミングの世界は、ときどき簡単なことを難しい名前で呼ぶ大会を開催している。
第31回・記載日：2026年9月18日
KAZU × AI 編集後記・第二章
サイトを直すたびに怖かった。「これを変更して全部壊れたらどうしよう」
だからZIPを保存する。v1.60。v1.61。v1.62……。気がつけばバージョンだらけ。
そこへGitHubがやってきた。変更履歴を残せる。前の状態も追える。
ここでようやく分かった。開発で強いのは、一度も失敗しない人ではない。失敗しても戻れる人なのだ。
これはかなり気が楽になる。もっとも、戻す場所を間違えたら、また別の冒険が始まる。
第32回・記載日：2026年9月18日
KAZU × AI 編集後記・第二章
パソコンでサイトを作る。普通はそう考える。ところが私はiPhoneでもやり始めた。
ファイルを開く。GitHubを見る。Cloudflareを見る。アップロードする。できる。ただし画面が小さい。
「…」を探す。ない。スクロールする。まだない。横を見る。いた。
プログラミングを勉強しているはずなのに、一番上達したのは小さなボタンを発見する能力だったかもしれない。
それでも分かった。「iPhoneだからできない」ではない。iPhoneなら、iPhoneなりの戦い方がある。
第33回・記載日：2026年9月18日
KAZU × AI 編集後記・第二章
GitHubにはファイルがある。Cloudflareには公開サイトがある。問題は、この二人がまだ別々に働いていることだった。
そこで連携。GitHubを更新する。Cloudflareが気づく。そして公開する。
初めてその流れを見たとき、「お前たち、いつの間にそんなに仲良くなったんだ」と思った。
昨日までZIPを抱えて右往左往していた人間を横目に、コンピューター同士が勝手に仕事を始める。
少し寂しい。でも、ものすごく便利である。
第34回・記載日：2026年9月18日
KAZU × AI 編集後記・第二章
これまでは、ファイルを作る。ZIPにする。アップロードする。公開する。確認する。毎回この繰り返しだった。
ところがGitHubとCloudflareを連携すると、その一部を機械に任せられる。つまり、自分の仕事を自分で機械に奪わせている。
でもこれは歓迎すべき失業である。単純作業を機械に渡せば、人間は文章を考えたり、新しい機能を作ったりできる。
自動化とは、人間を不要にすることではなかった。
人間が、人間にしかできない仕事へ戻るための仕組みだった。
第35回・記載日：2026年9月18日
KAZU × AI 編集後記・第二章
「自動化」なんと魅力的な言葉だろう。一回設定すれば、あとは全部勝手にやってくれる。そんな魔法を想像していた。
ところが実際にやってみると、「どのファイルですか？」「どこへ公開しますか？」「失敗したらどうしますか？」「どれが最新版ですか？」質問が多い。
自動化は魔法使いではなかった。ものすごく几帳面な新人だった。
人間が「まあ、この辺でいいだろう」と済ませていた部分を、一つ一つ決めなければ動いてくれない。
自動化するには、まず人間の仕事を整理しなければならない。だから自動化はゴールではない。仕事のやり方そのものを見直す先生なのだ。
そして今日も、その先生から宿題が出る。「最新版はどれですか？」 ……そこからか。
第36回・記載日：2026年9月18日
KAZU × AI 編集後記・第三章
GitHubにファイルを置いた。するとCloudflareを見ると、数分前に新しいバージョンができている。
「誰がやった？」 私ではない。いや、正確には私がGitHubを更新した。でもCloudflareのボタンは押していない。勝手に働いている。
これが連携だった。昨日まで「次はどのボタン？」と探していたのに、今日はボタンを押さなくても次へ進む。
便利になった。しかし初心者には新しい問題が発生する。便利すぎて、何が起きたのか分からない。
自動化とは、人間の仕事を減らすと同時に、人間に「仕組みを理解しなさい」という新しい宿題を出してくるものらしい。
第37回・記載日：2026年9月18日
KAZU × AI 編集後記・第三章
GitHubは更新した。Cloudflareも動いた。公開サイトを開く。変わっていない。
なぜだ。GitHubか。Cloudflareか。iPhoneか。キャッシュか。それとも私か。容疑者が多すぎる。
しかし調べていくうちに分かった。自動化が正常でも、元のファイルに新しい内容が入っていなければ、新しい内容は公開されない。
当たり前である。ものすごく当たり前である。しかし自動化を覚えたばかりの人間は、機械が何とかしてくれるような気がしてしまう。
機械は正確だった。間違ったものを渡せば、間違ったものを正確に公開してくれる。
第38回・記載日：2026年9月18日
KAZU × AI 編集後記・第三章
編集後記を追加した。第27回、第28回、第29回……。かなり書いた。公開サイトを見る。第26回まで。
もう一度見る。やっぱり第26回まで。スクロールしても第26回。「27はどこへ行った？」
編集後記が家出したわけではない。調べてみると、公開されているファイルそのものが第26回までだった。
ここで大事なことを覚えた。「原稿を書いた」「ファイルに入れた」「GitHubに保存した」「Cloudflareが公開した」これは全部、別の作業である。
頭の中では一本の道でも、コンピューターにとっては四つの関所だった。
第39回・記載日：2026年9月18日
KAZU × AI 編集後記・第三章
v1.92。v1.93.1。v1.96。全員が言う。「私が最新版です」
困る。パソコンにもある。iPhoneにもある。GitHubにもある。Cloudflareにもある。
ファイル管理を甘く見ると、最新版という言葉が急に信用できなくなる。
そこでルールを決めることにした。作業中の最新版。GitHub上の最新版。現在公開されている最新版。この三つは同じとは限らない。
これは今回かなり大きな発見だった。
第40回・記載日：2026年9月18日
KAZU × AI 編集後記・第三章
公開前にiPhoneで確認しよう。ZIPを解凍した。index.htmlもある。よし、押してみよう。LetsViewが開いた。
……君じゃない。私はホームページを見たい。画面ミラーリングをしたいわけではない。
もう一度やる。またLetsView。どうやらiPhoneがHTMLをLetsViewで開こうとしている。
サイトを作っているのに、サイトを見る前にiPhoneとの交渉が必要になった。
プログラミングでは、コード以外のところから敵が現れる。しかも、その敵はだいたい悪気がない。
第41回・記載日：2026年9月18日
KAZU × AI 編集後記・第三章
画面を開いた。真っ白。エラー表示もない。警告もない。ただ白い。初心者にとって、これはかなり怖い。
赤いエラーならまだいい。「ここが悪い」と言ってくれている。白い画面は何も言わない。無言でこちらを見ている。
しかし、ここでも学んだ。白画面になったからといって、すぐ公開版を変更してはいけない。
まず、ファイルなのか。開き方なのか。ブラウザなのか。公開側なのか。原因を分ける。
直す前に、犯人を決める。 これはサイト作りでかなり重要だった。
第42回・記載日：2026年9月18日
KAZU × AI 編集後記・第三章
初心者のころは、不具合が出るとすぐ直したくなる。新しいファイルを作る。アップロードする。また違う。さらに直す。
気がつけば、何を直していたのか分からなくなる。
今回覚えたのは、逆だった。おかしいときほど、いったん公開版を触らない。正常に動いている版を残す。新しい版は別に作る。確認してから入れ替える。
何もしないことが、一番安全な操作になる瞬間がある。
「押さない」という操作もあるのだ。
第43回・記載日：2026年9月18日
KAZU × AI 編集後記・第三章
Cloudflareのデプロイ画面を開いた。そこには、Add files via upload、main、9分前、そしてGitHub側の情報。
あった。GitHubからCloudflareへ変更が届いている証拠だ。
ここでようやく分かった。連携は壊れていなかった。機械はちゃんと働いていた。問題は別の場所だった。
何時間も疑っていた相手が無実だったと分かった瞬間である。
Cloudflareさん、疑ってすみませんでした。
第44回・記載日：2026年9月18日
KAZU × AI 編集後記・第三章
最初は全部手作業だった。ファイルを作る。ZIPにする。アップロードする。公開する。確認する。
今は少し違う。人間がGitHubに正しいファイルを置く。Cloudflareが受け取る。自動で公開する。
まだ完全自動ではない。失敗もする。確認も必要だ。でも確実に変わった。私は少しずつ、「ボタンを押す人」から「流れを作る人」へ移っている。
プログラミングを始めたころは、コードを書けるようになることが目標だった。ところが実際にサイトを作ってみると、その先には、保存する。守る。つなぐ。確認する。自動化する。という世界があった。
そして次の目標も見えてきた。「正しいファイルを置いたら、安全に自動公開されるサイト」
ここまで来たら、もう最初のころとは違う。ただし最後に一つだけ確認する。「で、最新版はどれだ？」
第23回・記載日：2026年9月15日
KAZU × AI 編集後記
朝の私は甘かった。今日やることは三つ。翻訳機能の修正、語彙の整理整頓、ボタンの配置。文字にすると、たったこれだけである。
ところが最初の翻訳から止まった。パソコンでは動く。iPhoneでは動かない。
直す。「これで大丈夫」。iPhoneで押す。……動かない。また直す。「今度こそ」。……まだ動かない。
Google翻訳、読み込み、ブラウザ、Cookie、タイミング、Safari。調べるほど登場人物が増えていく。
以前、APIを「外部サービスへつながる道路」と考えた。今日、その説明に一行追加したくなった。
一個直して二歩進む。ドカン。また直す。三歩進む。ドカン。
そして何度目かの修正。iPhoneで翻訳ボタンを押す。
……動いた。
たった一つの機能なのに感動した。苦労して直した一つは、ただの一つではない。そこまでに使った時間も失敗も全部、そのボタンの中に入っている。
昨日まで当たり前だったことが、今日は奇跡になる。そんな一日が始まった。
第24回・記載日：2026年9月15日
KAZU × AI 編集後記
翻訳だけで終わるはずがない。次は語彙の整理整頓。そしてボタンの配置だ。
日本語なら「あいうえお順」が分かりやすい。英語ならA–Zが自然だ。だったら両方用意すればいい。言うのは簡単である。
語彙を整理してパソコンを見る。「いいじゃん」。iPhoneを見る。「……なんか違う」。iPhoneを直して「いいじゃん」。パソコンを見る。「……今度はこっちが気になる」。
今日やったのは、パソコンで直してiPhoneで確認しただけではない。パソコンも直した。iPhoneも直した。
翻訳を優先するとボタンが気になる。ボタンを大きくすると画面が窮屈になる。語彙を増やすと探しにくくなる。片方だけ完璧でもダメだった。
ここまで来ると、プログラミングというより家族会議である。
翻訳さんを立てればボタンさんが拗ねる。iPhoneさんを優先すればパソコンさんがこちらを見る。語彙さんを増やせば画面が「狭いです」と訴える。
今日分かった。プログラムに必要なのは知識だけではない。
翻訳、語彙、ボタン。大きく三つを、PCとiPhoneの両方で整えた。
そして最後に出た言葉が「完成！」ではなかった。
機械を相手にしているはずなのに、最後は健康観察のようになった。
第25回・記載日：2026年9月15日
KAZU × AI 編集後記
気がつけば夜だった。丸一日である。
翻訳を直した。語彙を整理した。ボタンを整えた。パソコンも直した。iPhoneも直した。
直す。見る。動かない。また直す。動く。喜ぶ。別のところを見る。また気になる。
最後にCloudflareの画面を開いた。
暗号化リクエスト 458。暗号化率 98.71%。暗号化された帯域幅 391.84MB。
さらに、キャッシュリクエスト 400。キャッシュ率 86.21%。
もちろん458人が来たという意味ではない。今日は自分でもパソコンとiPhoneから何度もアクセスした。それでも、朝から整備していたサイトが数字で返事をしてくれたように見えた。
朝、APIという道路で地雷を踏んだ。昼、翻訳と格闘した。午後、語彙とボタンを整えた。夜、PCとiPhoneのバランスを取った。
そして最後に道路を見ると、ちゃんと車が走っていた。
今日一番学んだのは、ホームページは「作ったら終わり」ではないということだった。
道路を作る。穴を直す。標識を整える。地雷を撤去する。そして、ときどき様子を見る。
整備することは大変だ。でも、一つ直るたびに感動する。今日は大きく三つ直した。だから三回くらい感動してもいい。
さて、明日の朝もちゃんと動いているだろうか。
……最後にもう一度確認しておこうか。
いや、やめよう。
第26回・記載日：2026年9月15日
KAZU × AI 編集後記・開発実況中継
午前5時すぎ。
本日の最初の事件は翻訳。その次は用語集。パソコン側を直したと思ったら、今度はiPhone側です。
修正が一段落し、Cloudflareの管理画面へ。LCP、INP、CLS。次々にアルファベットが登場します。
こちらはまだ工事中のつもりです。玄関を直し、翻訳を直し、用語集を直している。その間に、もうお客さんが入っていました。
もちろん、アクセス数がそのまま人数という意味ではありません。国の判定も完全ではありません。それでも、手元にあったHTMLが公開され、外からアクセスされた記録が残ったことは確かです。
続いて「リファラ」を確認。そこには m.facebook.com、facebook.com、www.facebook.com の文字が並びました。
昨日まで、Facebookに紹介文を書きながら「誰か見るのかな」と半信半疑でした。ところが、アクセス解析にはFacebook系から来た記録が残っていました。
数日前まで、このサイトは自分の手元にあるファイルでした。Cloudflareに置き、翻訳を付け、用語集を増やし、バグを出して、直して、またバグを出して、また直す。
そして今日、数字の向こう側に「訪問」が見えました。
用語集か。教材か。記事か。それとも、この編集後記か。
「お客さんは家のどの部屋に入ったのか？」
ホームページ制作を始めたはずなのに、今度はアクセス解析まで始まりました。
「ゼロから始める」と名前を付けたサイトが、本当にゼロではなくなった日。
今日の数字は、この小さな家の玄関に残った最初の足あとでした。
KAZU × PARTNERS
「ゼロから始めるプログラム言語」では、サイトの成長に合わせて、スポンサー・パートナー・作品紹介・PR掲載の仕組みを少しずつ整えていく予定です。
このサイトは、プログラミングをゼロから学びながら、実際に作り、失敗し、修正し、その過程まで公開していく学習サイトです。
将来的には、学ぶだけではなく、作った作品を紹介する場所、新しいサービスを知ってもらう場所、人と人、作品と企業がつながる場所へ育てていきたいと考えています。
プログラミング、AI、Web制作、教育、PC・IT機器、業務改善など、当サイトの内容と関連するサービスや活動を中心に検討します。
個人の作品や小さなプロジェクトについても、内容を確認したうえで紹介できる仕組みを作っていく予定です。
スポンサー契約や有料掲載の場合は、読者に誤解がないよう「スポンサー」「PR」「広告」などを分かりやすく表示します。掲載内容については、サイトとの相性や安全性を確認したうえで掲載します。
広告をたくさん並べることが目的ではありません。「これは面白い」「これは初心者にも役立ちそう」「この作品をもっと多くの人に知ってほしい」と思えるものを紹介できるページを目指します。
現在、スポンサー・PR掲載の仕組みを準備中です。お問い合わせ方法、掲載条件、料金、掲載期間などについては、準備が整い次第このページでお知らせします。
KAZU
ゼロから始めるプログラム言語
ゼロから始めるプログラム言語 ｜ 更新日：2026年9月18日
当サイトでは、皆さまに安心してご利用いただけるよう、プライバシーに配慮し、サイトの運営に必要な情報を適切に取り扱うよう努めています。
運営者：KAZU
対象サイト：zero-kara-prog.mmdei.workers.dev
情報の取り扱いに関するお問い合わせは、サイト内のお問い合わせ窓口からお願いいたします。
お問い合わせの際にお送りいただいた表示名、連絡先、メッセージなどの情報は、お問い合わせへの回答、必要なご連絡、問題の確認・対応のために利用します。
法令に基づく場合などを除き、必要なく第三者へ提供することはありません。
当サイトでは、ページの配信、安定したサービス提供、不正アクセスへの対応、障害調査などのためCloudflareを利用しています。その際、IPアドレス、アクセス日時、アクセス先、端末・ブラウザーに関する情報など、アクセスに伴う技術的な情報がCloudflare側で処理・記録される場合があります。
また、サイトの利用状況を把握し、内容や使いやすさを改善するため、Cloudflare Web Analyticsなどのアクセス解析機能を利用する場合があります。
これらの情報は、サイトの運営・改善、障害対応および安全管理など、記載した利用目的の範囲内で利用します。
学習済みの記事などの情報は、次回も続きから利用できるよう、お使いのブラウザーのローカルストレージ等に保存する場合があります。当サイトの学習進捗保存機能は、この情報を運営者へ送信することを目的としたものではありません。
外部サービスを利用した場合は、そのサービスの仕様によりCookie等が利用される場合があります。ブラウザーの設定からCookie等を制限・削除できる場合があります。
当サイトでは、ページ配信、アクセス解析、セキュリティ、お問い合わせ、翻訳などのため外部サービスを利用する場合があります。外部サービスでは、サービス提供に必要な範囲で情報が処理される場合があります。
今後、広告配信サービスやアフィリエイト広告を導入する場合は、利用するサービスや情報の取り扱いについて必要に応じて本ページへ追記します。法令や利用サービスの規約上、同意等が必要となる場合は、必要な対応を行います。
運営者が保有する個人情報は、法令に基づく場合などを除き、本人の同意なく第三者へ提供しません。サイト運営上必要な範囲で外部サービスを利用・委託する場合は、必要に応じて適切な取り扱いに努めます。
管理用アカウントへのアクセスを適切に管理するなど、取り扱う情報に応じた安全管理に努めます。お問い合わせ情報などは利用目的に必要な期間取り扱い、法令上の保存義務がある場合を除き、必要性がなくなった情報は適切に整理・削除するよう努めます。外部サービス側の保存期間については、各サービス提供者の方針が適用される場合があります。
運営者が保有する個人情報について、法令に基づく開示、訂正、利用停止等をご希望の場合は、サイト内のお問い合わせ窓口からご連絡ください。必要な本人確認を行ったうえで、法令に従って対応します。
サイトの機能や利用するサービス、法令等の変更に応じて、本プライバシーポリシーを変更する場合があります。変更した内容は当サイト上でお知らせします。
制定・最終更新：2026年9月18日
学習レクチャー・2026年9月15日更新
HTMLで家の骨組みを作り、CSSで内装を整え、JavaScriptでボタンを動かした。
ようやく落ち着けると思ったところへ、新しい人が来た。
Python「作業員のPythonです。」
KAZU「また覚えるの？ もう頭の中、満室なんだけど。」
Python「今日は一行だけです。」
KAZU「その言葉、前にも聞いたな。一か所直すだけって言われて、夜になった。」
Pythonは黙って、短いコードを置いた。
print("こんにちは、Python！")これをPythonの実行環境で動かすと、実行結果の欄に次の文字が出る。
こんにちは、Python！KAZU「……それだけ？」
Python「それだけです。」
KAZU「来たばかりなのに、あまり働かないね。」
Python「頼まれた仕事は終わりました。」
どうやら、この作業員は勝手に気を利かせない。頼んだことを、頼んだとおりにする。それが長所でもあり、こちらが頭を使う理由でもある。
学習レクチャー・2026年9月15日更新
ここで出てきた print() は、文字や計算結果などを表示するための関数だ。関数は、ひとまず「名前を呼んで仕事を頼める道具」と考えよう。
丸かっこの中に、表示してほしいものを書く。文字を書くときは、" などの引用符で囲む。
では、数字ならどうだろう。
print(3 + 2)
print("3 + 2")結果はこうなる。
5
3 + 2KAZU「同じこと書いたつもりなのに。」
Python「上は計算です。下は『3 + 2』という文字です。」
引用符は飾りではなかった。「これは文字として扱ってください」という目印だったのだ。
学習レクチャー・2026年9月15日更新
調子が出てきたKAZUは、さっそく挨拶を変えてみた。
print("今日もお疲れさまです")今度は自分の言葉が表示された。
たった一行。でも、見本を眺めているだけの状態から、自分で指示を変える側へ一歩進んだ。
なお、このコードはPythonを動かせる環境で実行する。HTMLにそのまま貼るだけでPythonが動くわけではない。作業員にも、働くための持ち場が必要なのである。
KAZU「今日のところは、挨拶ができれば合格にしよう。」
Python「ありがとうございます。次は数字を覚えます。」
KAZU「急に職場の新人研修みたいになってきたな。」
print("3 + 2") を実行すると、何が表示される？
A．5
B．3 + 2
C．何も表示されない
ヒント：引用符の中は文字として扱われる。
答え：B。計算してほしいときは、print(3 + 2) と書く。
挨拶の部分を、自分の好きな言葉に変えてみよう。変えるのは引用符の内側だけ。まずは「一か所変えて、結果を見る」を体験すれば十分だ。
学習レクチャー・2026年9月15日更新
挨拶ができるようになったPythonに、今日は在庫の確認を頼むことにした。
KAZU「手袋が少なくなったら教えて。」
Python「少ないとは、いくつですか？」
KAZU「そこは雰囲気で。」
Python「雰囲気は、まだ受け取っていません。」
人間なら棚を見て「そろそろ危ないかな」と感じる。しかし、プログラムには判断の基準を渡す必要がある。
そこで、手袋の在庫が5より少なければ知らせてもらうことにした。
stock = 3
if stock < 5:
print("手袋の発注を確認")stock は、在庫数につけた名前だ。こうした名前を変数という。
stock = 3 は、「stockという名前で、3を使えるようにする」という指示。最初は、名前のついた箱に数字を入れるイメージでもよい。
ただし、この = は算数の「左右が等しい」という意味とは違う。プログラムでは、値を変数に代入するために使っている。
学習レクチャー・2026年9月15日更新
次の if は「もし」という意味だ。
stock < 5 は「在庫が5より少ない」。条件に当てはまると、その下の表示が実行される。
KAZU「じゃあ、在庫が5なら？」
Python「表示しません。」
KAZU「5も少なくない？」
Python「ご指示は『5より少ない』でした。」
この作業員、なかなか手ごわい。でも間違ってはいない。
5も含めたいなら、条件を stock <= 5 に変える。小さな記号一つで、判断の境界が変わるのだ。
もう一つ大切なのが、print の前にある空白だ。Pythonでは、行頭の字下げで処理のまとまりを表す。この例では「条件に当てはまったときにする仕事」を、一段下げて書いている。通常は半角スペース4個を使う。
KAZU「空白にも仕事があるのか。」
Python「私の職場では、空白も勤務中です。」
学習レクチャー・2026年9月15日更新
続いて、同じ確認を3回表示してみる。
for i in range(3):
print("確認", i + 1)結果は「確認 1」「確認 2」「確認 3」。
for は、順番に取り出した値を使って処理を繰り返す。ここでは range(3) から0、1、2を取り出し、表示するときに1を足している。
変数で覚える。ifで判断する。forで繰り返す。
別々だった道具が、少しずつ仕事の形になってきた。
stock < 5 という条件で、stockが5のとき、発注確認は表示される？
A．表示される
B．表示されない
ヒント：「より少ない」と「以下」は違う。
答え：B。5も含めるなら stock <= 5 と書く。
stockを4、5、6に変えて試そう。条件の境目を確かめると、プログラムが何を判断しているか分かりやすい。
学習レクチャー・2026年9月15日更新
KAZU「手袋だけじゃなくて、ペーパーもゴミ袋も見てほしい。」
Python「一覧をください。」
KAZU「棚を見れば分かるじゃん。」
Python「私は今、その棚を見る機能を持っていません。」
便利なプログラムも、渡されていない情報までは分からない。
そこで、品名と在庫数を組にした一覧を用意した。
items = {
"手袋": 4,
"ペーパー": 9,
"ゴミ袋": 2
}
for name, stock in items.items():
if stock < 5:
print(name, "→ 発注候補")実行すると、こう表示される。
手袋 → 発注候補
ゴミ袋 → 発注候補KAZU「おお、二つ見つけた。」
Python「ペーパーは在庫9なので、今回は表示していません。」
学習レクチャー・2026年9月15日更新
最初の { } で囲まれた部分は、辞書と呼ばれるデータの持ち方だ。品名を手がかりに、その在庫数を扱える。
ここでは「手袋」と4、「ペーパー」と9、「ゴミ袋」と2が、それぞれ組になっている。
items.items() は、その名前と数の組を順番に取り出すために使っている。取り出した品名を name、在庫数を stock として受け取り、一件ずつ条件を確かめる。
KAZU「つまり、一覧を順番に見て、少ないものだけ教えるのか。」
Python「はい。」
KAZU「じゃあ明日には届くね。」
Python「何がですか？」
KAZU「手袋。」
Python「注文はしていません。」
ここが大事なところだ。このプログラムは、発注候補を表示するだけ。注文を送る処理も、業者と通信する処理も入っていない。
「自動化できた」という言葉は、どこまで自動になったのかを確かめないと、意外なすれ違いを生む。
学習レクチャー・2026年9月15日更新
さらに、今回は全商品を同じ基準で判定している。実際には、手袋5箱とゴミ袋5枚では意味が違う。箱・袋・枚などの単位や、商品ごとの最低在庫も決める必要がある。
KAZU「作ったら終わりかと思ったら、仕事の決め事まで出てきた。」
Python「決め事がはっきりすると、私も働きやすくなります。」
自動化は、曖昧な仕事をそのまま機械へ投げることではない。人が基準を整理して、繰り返せる形にすることでもある。
このプログラムがしていることはどれ？
A．業者へ注文を送る
B．在庫が5未満の商品を表示する
C．届いた商品の在庫を増やす
答え：B。画面への表示と、実際の注文は別の処理。
一覧に "洗剤": 1 を追加しよう。前の項目との間にカンマが必要なことにも注意して、発注候補に洗剤が出るか確かめてみよう。
学習レクチャー・2026年9月15日更新
Pythonに在庫確認を頼めるようになった。
しかし、毎回コードを開いて在庫数を書き直すのは、少し面倒だ。
KAZU「昨日は4だったけど、今日は3。明日は納品で増える。これ、どこかにまとめて置けない？」
そこで登場したのが、データベースだった。
SQL「倉庫の準備ですね。」
KAZU「あなたが倉庫？」
SQL「私は倉庫へ指示を出すための言葉です。」
データベースが情報を保存して管理する仕組み。SQLは、その中の情報を取り出したり変更したりするための言語だ。
倉庫と、倉庫への頼み方は別だった。
学習レクチャー・2026年9月15日更新
まずは在庫表を見てみよう。
| id | item | stock |
|---|---|---|
| 1 | 手袋 | 4 |
| 2 | ペーパー | 9 |
| 3 | ゴミ袋 | 2 |
このような表を「テーブル」と呼ぶ。ここでは supplies という名前をつけることにする。
横一列が「行」。一件分のデータだ。縦の項目が「列」。この表にはid、item、stockという三つの列がある。
KAZU「表なら、Excelでも見たことがある。」
SQL「その感覚は役に立ちます。まずは一行に何を入れるか、各列が何を意味するかをそろえましょう。」
学習レクチャー・2026年9月15日更新
では、一番左のidは何だろう。
これは、それぞれの行を区別するための番号だ。同じような品名があっても、どの行を指しているかをはっきりさせられる。
KAZU「手袋って名前で分かるんじゃない？」
SQL「SサイズとMサイズがあったら？」
KAZU「小さい手袋と、普通の手袋。」
SQL「普通とは？」
また出た。プログラムの世界では「普通」がなかなか通用しない。
実際の管理では、サイズや単位なども項目として持たせると、意味がはっきりする。表に情報を詰め込む前に、何をどう区別するかを考えるのが大切なのだ。
なお、先ほどのPythonの辞書は、あの例だけではプログラム終了後に変更をファイルへ保存しない。残しておきたい情報には、ファイルやデータベースへ保存する処理が必要になる。
KAZU「覚えてくれたと思ったのに、帰ると忘れるのか。」
SQL「だから、記録を残す場所を用意します。」
人もプログラムも、申し送りの仕組みが大切らしい。
表の「一件分のデータ」に当たるのは？
A．行
B．列
C．テーブル名
答え：A。列は品名や在庫数などの項目を表す。
自分の在庫表を作るなら、何の列が必要か考えよう。「品名」「在庫数」に加えて「単位」があると、4箱なのか4枚なのかを区別できる。
学習レクチャー・2026年9月15日更新
倉庫に品物の情報が集まった。
最初は3件だった一覧も、30件、100件と増えていく。全部を眺めていると、どこまで確認したか分からなくなる。
KAZU「在庫が少ないものだけ見せて。」
SQL「条件をどうぞ。」
KAZU「あなたもか。」
Pythonとのやり取りで学んだことが、ここでも役に立った。「少ない」を数字で決めればよい。
SELECT item, stock
FROM supplies
WHERE stock < 5;これは、前回の supplies というテーブルがある前提の例だ。
頼み事は、三つに分かれている。
SELECT item, stock は「品名と在庫数を見せて」。
FROM supplies は「suppliesという表から」。
WHERE stock < 5 は「在庫が5より少ない行だけ」。
前回の表なら、手袋4とゴミ袋2が見つかる。
KAZU「文章みたいに読めるね。」
SQL「順番に読むと、何を頼んだか整理できます。」
学習レクチャー・2026年9月15日更新
では、「少ない順に見たい」ときはどうするのだろう。
SELECT item, stock
FROM supplies
WHERE stock < 5
ORDER BY stock ASC;ORDER BY は並べ方を指定する部分。ASC は小さい順を表す。これで、ゴミ袋2、手袋4という順番になる。
KAZU「さっきも、たまたま見やすい順だったけど。」
SQL「並び順が必要なら、明示してください。」
並び順を指定していない結果について、いつも同じ順番で出ると思い込まないことが大切だ。
学習レクチャー・2026年9月15日更新
もう一つ、よく見かける書き方がある。
SELECT *
FROM supplies;* は、この場合「すべての列」を意味する。表の中身を確認するには便利だが、画面で使う項目が決まっているなら、必要な列を指定すると目的が伝わりやすい。
SQLは魔法の検索係ではない。こちらが「何を」「どこから」「どんな条件で」と整理すると、必要な情報を取り出せる。
KAZU「探す技術というより、頼み方の技術でもあるんだね。」
SQL「その頼み方を、何度でも正確に実行できます。」
在庫が5より少ない行に絞っているのは、どの部分？
A．SELECT
B．FROM
C．WHERE
答え：C。SELECTは取り出す列、FROMは元の表、WHEREは行を絞る条件。
条件を stock >= 5 に変えたら、前回の表から何が出るだろう。答えは、在庫9のペーパー。記号を変えると、探す側が反対になる。
学習レクチャー・2026年9月15日更新
品物が届いた。
手袋の在庫が増えたので、表を直すことにする。
KAZU「idが1の手袋を、在庫8にして。」
UPDATE supplies
SET stock = 8
WHERE id = 1;UPDATE supplies は「suppliesを更新する」。
SET stock = 8 は「在庫数を8にする」。
WHERE id = 1 は「idが1の行を対象にする」。
ここでの「8にする」は、「8増やす」とは違う。元が4なら、変更後は8。12にはならない。
KAZU「日本語だと、つい『8追加して』とか言っちゃいそうだね。」
SQL「そこは結果が変わるので、区別してください。」
学習レクチャー・2026年9月15日更新
そして、この回の最重要人物がWHEREさんだ。
もし最後の条件を書かなければ、この文はテーブル内の全行を更新対象にする。手袋だけ直したかったのに、ペーパーもゴミ袋も在庫8になる。
KAZU「みんな仲良く8？」
SQL「在庫管理では困ります。」
「エラーが出ない」ことと「意図どおり」は同じではない。文法が正しくても、頼み方が間違っていれば、間違った仕事が正確に実行される。
そのため、変更する前に同じ条件で対象を確認する習慣が役に立つ。
SELECT id, item, stock
FROM supplies
WHERE id = 1;ここで手袋の行が出ることを確認してから、更新を考える。変更後の結果や、変更件数も確かめたい。
学習レクチャー・2026年9月15日更新
また、データを追加する命令は INSERT、行を削除する命令は DELETE だ。削除も対象条件を間違えると影響が大きいので、練習には専用のデータを使おう。
実際のシステムでは、権限やバックアップ、変更履歴、必要に応じたトランザクションなども組み合わせる。トランザクションは、関連する変更をひとまとまりとして扱う仕組みだ。ただし「何でも後から戻せる魔法」ではなく、確定前かどうかなどの条件がある。
KAZU「便利になるほど、確認が大事になるね。」
SQL「速く直せる道具は、速く間違えることもできます。」
KAZU「WHEREさん、今日は残業お願いします。」
SET stock = 8 の意味は？
A．在庫を8増やす
B．在庫を8にする
C．在庫8の商品だけ探す
答え：B。数を指定して置き換える処理。
コードを書く前に、「どの行を」「どの値に変えるか」を一文で書いてみよう。対象を言葉にできないときは、更新する前に条件を整理するところから始めよう。
学習レクチャー・2026年9月15日更新
自分のページができた。情報を保存する場所も見えてきた。
次に欲しくなったのは、自分の手元にはない情報だった。
KAZU「ページに甲府の天気を出したい。」
Python「天気の情報はありますか？」
KAZU「窓の外は見える。」
Python「明日の分は？」
それは困る。明日の空は、今の窓から見えない。
そこで登場するのがAPIだ。
API「天気情報を提供するサービスへ、決められた方法で問い合わせることができます。」
KAZU「外へつながる道路ってこと？」
API「そのイメージは役立ちます。ただ、道路の先には受付があります。」
学習レクチャー・2026年9月15日更新
好きなところへ勝手に入って、欲しいものを持って帰る仕組みではない。どの窓口へ、どんな形式で頼むかが決まっている。
たとえば「甲府の天気」を頼むつもりでも、相手は都市名ではなく緯度と経度を必要としているかもしれない。
KAZU「『甲府です、よろしく』じゃ駄目なの？」
API「受付が受け取れる形にしてください。」
このように、プログラム同士がやり取りするための窓口やルールがAPIだ。この話ではインターネット経由のAPIを扱うが、APIという言葉自体は、もっと広い場面でも使われる。
返ってきた情報は、そのまま完成した天気画面になるとは限らない。気温や天気のコードなどを受け取り、自分のページ側で文字やアイコンにして表示する場合もある。
つまり、「情報をもらう仕事」と「見やすく見せる仕事」は、分けて考えられる。
KAZU「食材が届いても、料理はこっちでする感じ？」
API「そのたとえなら分かりやすいですね。」
学習レクチャー・2026年9月15日更新
また、サービスによっては利用登録や認証、料金、回数制限がある。必要な鍵の扱いもサービスごとに確認する。秘密にするべきキーを、誰でも読めるHTMLやJavaScriptへ書いてはいけない。
道路が一本できると、外の力を借りられる。ただし、相手の受付時間やルールを無視して走れるわけではないのだ。
APIから天気のデータを受け取ったら、必ず完成した天気画面も一緒に届く？
A．必ず届く
B．データを受け取り、自分で画面を作る場合もある
答え：B。何が返るかは、そのAPIの仕様による。
「外からもらいたい情報」を一つ考えよう。次に、それを「自分の画面でどう見せたいか」も書いてみよう。取得と表示を分けると、必要な仕事が整理できる。
学習レクチャー・2026年9月15日更新
APIの受付へ頼み事を送ることになった。
KAZU「頼んだ。じゃあ結果を出して。」
API「まだ届いていません。」
KAZU「今、頼んだじゃん。」
API「返事が届くまで時間がかかります。」
人間同士なら当たり前のことだが、画面の中では忘れやすい。通信には時間がかかる。頼んだ瞬間に、答えが手元にあるとは限らない。
そこで今日は、JavaScriptからAPIへ問い合わせる流れを見てみる。
以下は、同じサイトに /api/example という窓口が用意され、JSONを返す前提の例だ。窓口そのものを作るコードではない。
async function loadExample() {
const response = await fetch("/api/example");
if (!response.ok) {
throw new Error(
`取得に失敗しました: ${response.status}`
);
}
const data = await response.json();
console.log(data);
}学習レクチャー・2026年9月15日更新
fetch() は、指定した場所へ通信するための関数だ。
await は、その処理の結果が得られるまで、この関数内の続きを待つために使う。その間ずっとブラウザ全体が止まる、という意味ではない。
async は、こうした非同期処理を扱う関数につける。
KAZU「専門用語が三人まとめて来たな。」
API「今日は『頼む、待つ、受け取る』が分かれば先へ進めます。」
response は、相手から返ってきた応答だ。そこには本文のほか、処理の結果を示すステータスなどがある。
ここで注意したい。404などのHTTPエラーが返っても、fetch() はそれだけで失敗として例外を投げるわけではない。そのため、response.ok で成功した応答かを確認している。
続いて response.json() で、本文をJSONとして読み取り、JavaScriptで扱える値にする。
たとえば、返事の本文が次のようなJSONだったとしよう。
{"city": "甲府", "temperature": 25}これは形式を説明するための架空の値で、現在の天気ではない。読み取った後は、data.city で都市名、data.temperature で気温の値を取り出せる。
学習レクチャー・2026年9月15日更新
なお、関数は定義しただけでは実行されない。呼び出して、失敗した場合も受け止める。
loadExample().catch(error => {
console.error(error);
});console.log() の出力先は開発者向けのコンソールだ。ページ本文へ表示するには、別途その処理を書く。
KAZU「窓口も必要。呼び出しも必要。画面表示も別。短いコードの裏に仕事があるね。」
API「一つずつ役割を分けると、困った場所も探しやすくなります。」
fetch("/api/example") と書くだけで、そのAPI窓口自体も作られる？
A．作られる
B．作られない
答え：B。これは既にある窓口へ問い合わせる処理。
コードを「送信」「成功確認」「本文の読み取り」「出力」に分けて読んでみよう。全部を暗記するより、それぞれが何を担当しているかをつかもう。
学習レクチャー・2026年9月15日更新
パソコンでは動いた。
KAZU「完成！」
ところがiPhoneで試すと、思ったように動かない。
KAZU「さっき完成したところなんだけど。」
API「別の環境でも確認できて、よかったですね。」
KAZU「励ましの角度が独特だね。」
通信する機能では、自分のコードだけでなく、ネットワークや相手のサービス、ブラウザの制約なども関わる。動かない原因がAPIとは限らない。ボタンの処理や画面の更新に問題がある場合もある。
だから、「APIが悪い」と決める前に、どこまで進んだかを確かめたい。
ボタンは反応したか。通信は送られたか。返事は来たか。受け取ったデータを表示できたか。
KAZU「道路が悪いと思ったら、玄関のドアが開いていないこともあるのか。」
API「あります。」
そして、原因を直すだけでなく、失敗したときの動きも用意する。
次の例は、前回と同じ窓口が存在する前提だ。
async function loadExample() {
try {
const response = await fetch("/api/example");
if (!response.ok) {
throw new Error(
`HTTPエラー: ${response.status}`
);
}
const data = await response.json();
console.log("取得できました", data);
} catch (error) {
console.error("取得できませんでした", error);
}
}
loadExample();HTTPエラーとは、通信先のサーバーからHTTPの返事が届いたものの、その返事が「処理を完了できなかった」ことを示している状態だ。たとえば、指定したページが見つからないときは404、サーバー側で問題が起きたときは500になる。
response.ok は、返事が成功扱いかどうかを確認するための値だ。ステータスが200番台なら通常は true、404や500のようなHTTPエラーなら false になる。
ただし、response.ok が false になっただけでは、catch へ自動的に移るわけではない。そこで throw new Error(...) を使い、こちらから「これは失敗として扱います」と知らせる。
throw は、問題が起きたことを知らせて、通常の処理を中断する指示だ。たとえるなら、受付で「この依頼は処理できません」と分かった時点で、次の作業を止め、非常口へ案内するようなものだ。
try の中で処理を行い、そこで起きた例外を catch で受け止める。例外とは、プログラムの途中で起きた予想外の問題を知らせる仕組みである。
たとえば、JSONではなく壊れた文字列が返ってきた場合、response.json() の読み取りに失敗して例外が起きる。ネットワーク自体に問題がある場合も、fetch() が例外になることがある。catch があれば、こうした問題を受け止め、エラー表示へ進められる。
学習レクチャー・2026年9月15日更新
ここで、ネットワークエラーとHTTPエラーは区別して考えよう。
ネットワークエラーは、サーバーからHTTPの返事を受け取る前に起きる問題だ。Wi-Fiが切れた、DNSで接続先を見つけられない、通信がタイムアウトしたなどがある。この場合、fetch() 自体が例外になり、response は作られない。
一方、404や500は、サーバーからHTTPの返事が届いたうえで、その内容が「見つからない」「サーバー側で問題が起きている」という意味を示している状態だ。この場合、fetch() は返事を受け取るため、通常は response が作られる。ただし response.ok は false になる。
つまり、次のように整理できる。
fetch() が例外になり、catch へ進むresponse.ok を確認し、必要なら throw して catch で扱う流れを短く言うと、こうだ。
「返事を受け取る」→「response.ok でHTTP上の成功か確認する」→「HTTPエラーなら throw する」→「catch が受け止める」。
ただし、ネットワークエラーの場合は、返事を受け取る前に fetch() が失敗する。そのため、response.ok を確認するところまで進まず、直接 catch へ移る。
KAZU「ネットワークエラーは返事が来ない。404や500は、返事は来たけれど内容が失敗なんだね。」
API「その違いを分けると、再試行するか、設定を直すかを判断しやすくなります。」
学習レクチャー・2026年9月15日更新
たとえば、エラーの種類を分けて表示するなら、次のように書ける。
async function loadExample() {
try {
const response = await fetch("/api/example");
if (response.status === 404) {
throw new Error("指定したAPIが見つかりません");
}
if (response.status >= 500) {
throw new Error("サーバー側で問題が起きています");
}
if (!response.ok) {
throw new Error(`HTTPエラー: ${response.status}`);
}
const data = await response.json();
console.log("取得できました", data);
} catch (error) {
console.error("取得できませんでした", error);
}
}この例では、404と500以上を先に分けている。404ならURLや窓口の設定を確認する必要がある。500以上なら、サーバー側の復旧を待つ、管理者へ連絡するなどの対応が考えられる。
ただし、実際のアプリでは、利用者にHTTPステータスをそのまま見せるのではなく、「情報が見つかりません」「サーバーが混み合っています」など、次の行動が分かる言葉に置き換えることも大切だ。
KAZU「同じ失敗でも、直し方が違うんだね。」
API「はい。返事がないのか、返事はあるが失敗なのかを見分けます。」
ただし、このコードの表示先はコンソールだ。実際の利用者には、画面上で「取得できませんでした。時間をおいて再度お試しください」などと知らせる必要がある。
KAZU「押したのに無言、が一番困るんだよ。」
API「処理中か、成功したか、失敗したかが分かると、次の行動を選べます。」
学習レクチャー・2026年9月15日更新
再試行とは、失敗した処理をもう一度やり直すことだ。ただし、何でも繰り返せばよいわけではない。まず、エラーを「再試行しても直りにくいもの」と「時間を置けば直る可能性があるもの」に分ける。
404のようにURLやAPIの指定が間違っているエラー、400番台の入力ミス、401や403のような認証・権限の問題は、同じ条件で繰り返しても解決しにくい。まずURL、入力値、認証情報、権限などを直す必要がある。
一方、ネットワークエラーや、429（短時間にアクセスしすぎたことを示すエラー）、一部の500番台エラーは、一時的な問題の可能性がある。時間を置いて再試行する設計を検討できる。ただし、500番台でも、処理の内容やAPIの仕様によっては再試行が安全とは限らない。
つまり、すべてのHTTPエラーを一律に再試行してはいけない。ステータスコードだけでなく、処理の種類、APIの仕様、エラーの内容を確認して判断する。
たとえば、天気を読むだけの処理なら、ネットワークエラーや一時的なサーバーエラーが起きたときに、回数を制限して再試行する設計は考えやすい。
function isRetryableStatus(status) {
return status === 408 ||
status === 429 ||
status >= 500;
}
function sleep(ms) {
return new Promise(resolve => {
setTimeout(resolve, ms);
});
}
async function loadWeather() {
const maxAttempts = 3;
for (let attempt = 1; attempt <= maxAttempts; attempt++) {
try {
const response = await fetch("/api/weather");
if (!response.ok) {
const error = new Error(
`HTTPエラー: ${response.status}`
);
error.status = response.status;
throw error;
}
return await response.json();
} catch (error) {
const isNetworkError =
error instanceof TypeError && error.status === undefined;
const isRetryableHttpError =
Number.isInteger(error.status) &&
isRetryableStatus(error.status);
const canRetry =
isNetworkError || isRetryableHttpError;
if (!canRetry || attempt === maxAttempts) {
throw error;
}
const baseDelay = 1000;
const exponentialDelay =
baseDelay * 2 ** (attempt - 1);
const jitter =
Math.floor(Math.random() * 300);
const delay = exponentialDelay + jitter;
console.warn(
`${attempt}回目の失敗。` +
`${delay}ms後に再試行します`
);
await sleep(delay);
}
}
}この例では、最大試行回数を3回にしている。最初の試行を1回目と数え、1回目に失敗したら待って2回目、2回目に失敗したら待って3回目を試す。3回目も失敗したら、それ以上は繰り返さず、最後のエラーを呼び出し元へ伝える。
学習レクチャー・2026年9月15日更新
再試行回数には、最初の試行を含めるかどうかで意味が変わる。ここでは maxAttempts = 3 を「合計3回試す」という意味にしている。設計書や画面表示でも、試行回数の数え方をそろえておく。
isRetryableStatus() では、408、429、500番台を再試行候補にしている。408はリクエストの処理が時間内に終わらなかったことを示す。429はアクセス回数の制限に達したことを示す。500番台はサーバー側の一時的な障害の可能性がある。
ただし、これはあくまで一例だ。APIによっては、503だけを再試行対象にしたり、429ではレスポンスの Retry-After ヘッダーに従ったりする必要がある。429を受け取ったら、固定の待ち時間ではなく、サーバーが指定した待ち時間を優先する設計も考えられる。
また、ネットワークエラーを TypeError だけで判定する方法は、環境によっては十分ではない。fetch() が返すエラーの種類や、アプリ側で定義したエラー情報を確認し、必要なら独自のエラー分類を用意する。ここでは、ネットワークエラーとHTTPエラーを区別する考え方を示すために簡略化している。
待ち時間には、指数バックオフを使っている。
baseDelay * 2 ** (attempt - 1) によって、待ち時間はおおむね1秒、2秒、4秒と伸びる。障害中のサーバーへ、短い間隔で何度もアクセスし続けることを避けやすい。
さらに、ランダムな短い時間を加えている。これをジッターという。同じ時刻に多くの利用者が一斉に再試行するのを避けるためだ。
ただし、待ち時間を無制限に伸ばしてはいけない。実際のアプリでは、1回あたりの最大待ち時間や、全体のタイムアウト時間も設ける。利用者を長く待たせすぎないよう、再試行中は画面に「再接続しています」などと表示し、最終的に失敗したら次の行動を案内する。
KAZU「再試行には、対象にしてよいエラー、回数、待ち時間、上限があるんだね。」
API「はい。『もう一度』を自動化する前に、どの失敗なら安全かを決めます。」
また、500番台でも、処理の内容によっては再試行が危険になる。天気の取得のように読むだけの処理なら比較的安全だが、注文や決済では、サーバーが処理を受け付けた後に返事だけ届かなかった可能性がある。
学習レクチャー・2026年9月15日更新
KAZU「ネットワークエラーなら、サーバーが何もしていないとは限らないのか。」
API「はい。返事が届かなかっただけで、裏側では処理が成功している場合があります。」
さらに、再試行には回数だけでなく、処理の性質も関係する。
注文や決済のように、サーバーの状態を変更する処理を、クライアント側から単純に自動再試行してはいけない。通信が切れた時点で、サーバーが処理を受け付けたかどうか分からないことがあるからだ。
KAZU「画面では失敗に見えても、裏では成功していることがあるのか。」
API「通信が切れた場所によっては、そういうことがあります。」
この場合、単純な再試行は危険だ。天気の取得なら「もう一度聞く」だけで済むが、注文は「もう一度実行する」ことになる。
二重処理とは、本来一回だけ行う仕事が、誤って二回行われることだ。たとえば、サーバーでは注文を受け付けたのに、返事が届く前に通信が切れることがある。画面に「失敗したかもしれません」と表示され、利用者がもう一度押すと、同じ商品が二つ注文される可能性がある。
そのため、注文や決済では、まず「再試行してよい処理」と決めつけず、注文履歴や決済状態を確認する。必要なら、サーバー側に状態確認用のAPIを用意し、元の依頼が処理済みか、未処理か、不明かを確認してから次の操作を決める。
また、同じ依頼を識別するための一意な注文番号やリクエストIDを使い、同じIDの依頼を二回受けても一回分として扱う仕組みを用意する。これは冪等性を確保するための設計である。決済や注文では、サーバー側でこの重複防止を行うことが重要だ。
KAZU「同じ依頼に同じ番号をつけて、二回届いても一回として扱うのか。」
API「はい。ただし、その仕組みがサーバー側で正しく実装されている必要があります。」
利用者が「注文する」ボタンを押したら、画面側でボタンを一時的に無効にする方法もある。ただし、これは連打を防ぐ助けにはなるが、通信切れによる再送まで完全に防ぐものではない。ボタンを無効にしただけで、二重注文を防げたと考えてはいけない。
注文や決済で通信が切れた場合は、「失敗したので、もう一度押してください」とすぐ案内するのではなく、「処理結果を確認しています」「注文履歴を確認してください」など、重複を避ける案内を優先する。状態が不明なまま、同じ処理を自動再試行しない。
一方、天気の取得のように読むだけの処理なら、再試行による二重注文の心配は比較的小さい。処理の種類に応じて、再試行してよいかを判断することが大切だ。
KAZU「再試行は、『もう一度聞く』のか、『もう一度実行する』のかで危険度が違うんだね。」
API「はい。読む処理と、注文・決済のように状態を変える処理は分けて考えます。」
学習レクチャー・2026年9月15日更新
待ち時間の上限、再試行の回数、以前のデータを見せる場合の更新日時。こうしたルールを決めるほど、使う人が困る場面を減らせる。
KAZU「まさにAPIは地雷原だね。」
API「だから地図と帰り道を作りましょう。」
「動いた」は大きな一歩だ。
けれど、ゴールの合図ではない。パソコンだけでなくiPhoneでも、通信が速いときだけでなく遅いときにも試す。成功時だけでなく、ネットワークが切れたとき、404が返ったとき、429が返ったとき、500が返ったとき、返事が遅れたときにも確認する。
動作確認とは、一度動いたと喜ぶことではない。どんな条件なら動き、どんな条件で失敗するのかを知ることだ。
失敗は起きるものとして、処理中・成功・失敗の状態を画面に示す。失敗時には、何が起きたかだけでなく、次に何をすればよいかも伝える。ネットワークエラーなら「接続を確認して、もう一度取得する」、404なら「設定やURLを確認する」、429なら「しばらく待ってから再度試す」、500なら「時間をおいて再度試す」など、原因に合った案内が必要だ。
注文や決済で結果が不明な場合は、「もう一度実行する」ではなく、「注文履歴や決済状態を確認する」と案内する。処理が完了していないことを確認できた場合に限り、重複を防ぐ仕組みを使って再実行を検討する。
KAZU「処理の種類だけでなく、失敗の種類によっても帰り道の案内が変わるんだね。」
API「はい。迷った人を同じ場所へ何度も走らせないことが大切です。」
一つ直ると感動する。三つ直れば、ちょっと自慢したくなる。けれど、その日の最後にもう一度、パソコンとiPhoneを手に取る。
「動いた」は大きな一歩。
その一歩を完成へつなげるのは、動作確認と、失敗したときの備えだ。
完成の声は、成功した画面だけでなく、ネットワークエラー、404、429、500などの失敗画面にも、それぞれの帰り道があることを確かめてからでも遅くない。
学習レクチャー・2026年9月15日更新
APIの処理が失敗したら、何でも無制限に再試行すればよい？
A．よい
B．原因や処理の内容に応じて判断する
答え：B。一時的なネットワークエラー、429、または一部のサーバー側の一時的な障害なら、回数と待ち時間を制限して再試行すると直ることがある。一方、404のようなURLの間違い、入力ミス、認証情報や権限の問題には設定や入力の修正が必要だ。
注文や決済では、通信が切れてもサーバー側で処理が成功している可能性がある。結果が不明なまま同じ処理を再試行すると、二重注文や二重決済になるおそれがあるため、まず注文履歴や決済状態を確認し、サーバー側の重複防止の仕組みも利用する。
自分の画面について、「処理中」「成功」「失敗」の三つの表示を考えよう。パソコンとスマートフォン、通信が速いときと遅いときでも試してみる。
失敗したときは、「何が起きたか」だけでなく、「次に何をすればよいか」も表示する。ネットワークエラー、404、429、500などで、再試行してよいのか、URLや設定を直すのか、時間をおいて待つのかを考えよう。
再試行する場合は、対象にするエラー、合計の試行回数、指数バックオフによる待ち時間、最大待ち時間を決める。無限に繰り返さず、最後は利用者へ分かる形で失敗を伝える。
注文や決済のように状態を変更する処理では、通信が切れたときに自動再試行しない。まず処理結果や履歴を確認し、同じ依頼を一回だけ扱うための注文番号やリクエストIDなど、サーバー側の重複防止策があるかを確認する。
処理とエラーの種類に合った案内を用意し、利用者が迷わず戻れる道を作るところまでが、画面づくりの仕事だ。