AI・プログラミング初心者向け用語集

「リポジトリの差分を確認して、コミットしてください」。意味が分かれば短いお願いですが、初めて聞くと何をすればいいのか迷いますよね。

このページは、そんなときに戻ってくる用語集です。最初から全部覚えなくて大丈夫。意味 → 実際に出てくる場面 → 間違えやすい点の順に、必要な言葉だけ読んでください。

分野別に詳しく読む

このページは、作業の入口になる言葉を集めています。仕組みや関連語まで知りたいときは、次の記事につながっています。

AIの基本用語：LLM、トークン、コンテキスト、RAG
プログラミングの基本用語：ソースコード、実行環境、ライブラリ、フレームワーク、依存関係
Git・GitHubの基本用語：履歴の管理、マージ、Pull Request
Webサイトの基本用語：サーバー、ホスティング、ドメイン、DNS、CDN
ゲーム開発の基本用語：シーン、アセット、当たり判定、FPS
PCスペックの基本用語：CPU、GPU、メモリ、VRAM、画面性能

作業する場所に関する言葉

エディタ

文章やコードを編集するソフトです。プログラミング用のエディタには、コードの色分け、入力候補の表示、間違いを見つける補助などがあります。Visual Studio CodeやCursorが例です。

「エディタで開く」は、そのファイルを編集する画面で開くこと。ブラウザでWebページを見ることとは違います。

ここで大事なのが、保存と公開は別という点。エディタでサイトの文章を保存しても、公開先へ送っていなければ、インターネット上のサイトは変わりません。

IDE（統合開発環境）

コードを書く・実行する・不具合を調べる、といった道具をまとめた開発環境です。IDEはIntegrated Development Environmentの略です。

「エディタは文字を書くところ、IDEは開発の道具一式」と考えると入口がつかめます。ただし、エディタも拡張機能を追加すると多くの開発作業ができるため、境界がはっきりしない製品もあります。

名前の分類で迷うより、「授業で使う言語を実行できるか」「エラーを追いやすいか」を見た方が、道具を選びやすくなります。

ターミナル

文字の命令を入力し、結果を見るための画面です。VS Codeの下に開くターミナルも、別ウィンドウのターミナルもあります。

たとえば python hello.py と入力すると、Pythonに hello.py を実行させます。命令を解釈する仕組みはシェルと呼ばれ、PowerShellやBashなどがあります。ターミナルは画面、シェルはそこで命令を受け取る仕組み、と分けておきましょう。

同じような画面でも、シェルが違えば使える命令や書き方が異なります。説明に「PowerShell用」とあったら、どの画面でも同じように動くとは限りません。

CLI

文字のコマンドで操作する方式です。Command Line Interfaceの略で、ボタンやメニューを操作するGUIと対比して使われます。GUIはGraphical User Interfaceの略です。

ターミナルが「操作する画面」、CLIが「操作の方式」です。GitをCLIで使うなら、ボタンの代わりに git status のようなコマンドを入力します。

コマンドをコピーするときは、先頭の $ や PS C:\...> が入力待ちの表示として書かれていないか注意してください。説明によっては、それらは入力する文字に含まれません。

クラウド

ネットワーク経由で、外部のコンピューターの処理や保存機能などを利用する仕組みです。対して、手元のPC上で作業することを「ローカル」と呼びます。

AIに別の実行環境で作業を任せる、オンラインストレージへファイルを保存する、といった場面で出てきます。

ただし「クラウドへ送った」と「誰でも見られるように公開した」は同じではありません。共有範囲はサービスの設定で確認します。反対に、ローカルで動くアプリでもAIへの問い合わせ時に外部へ情報を送ることがあります。アプリの置き場所とデータの送信先は別です。

コードを管理する言葉

コードベース

一つの製品やプロジェクトを構成するコード全体です。設定ファイル、テストなども含めて呼ぶ場合があります。

Webサイトなら、トップページのファイルだけでなく、記事を表示する処理、共通デザイン、設定などがつながっています。「コードベースを調べる」は、そのつながりを見ながら必要な場所を探すことです。

AIに「このファイルだけ見て」と頼む場合と、「関連する呼び出し元も調べて」と頼む場合では、確認の範囲が変わります。

リポジトリ

Gitの話では、ファイルの履歴などを管理する場所を指します。「repo」と略されることもあります。

自分のPCにあるものをローカルリポジトリ、GitHubなど共有先にあるものをリモートリポジトリと呼びます。両者は自動的にいつも同じ内容になるわけではありません。

「PCでは直っているのにGitHubは古い」というときは、ローカルの変更をリモートへ送っていない可能性があります。送り方はpush・pullの入門で説明します。

Git（ギット）

ファイルの変更履歴を管理するツールです。いつ、何を変えたかを記録し、差分を比べたり、記録済みの状態を取り出したりできます。

GitとGitHubは別です。Gitは履歴管理の仕組み、GitHubはそのリポジトリを共有し、相談やレビューをするサービスです。GitはGitHubへ公開しなくても使えます。

ただし、Gitがあるだけで未保存の編集やPC上の全データが保護されるわけではありません。記録するファイルを選び、コミットする必要があります。Git公式の基礎でも、ファイルの状態が区別されています。

コミット

その時点のファイルの状態を、説明と一緒に履歴へ記録することです。変更をまとめて記録する、という言い方もします。

普段のファイル保存とは違います。Gitでは、記録したい変更を選ぶステージングを行い、その内容をコミットします。「見出しを修正した」など、何をした記録なのか分かる説明をつけましょう。

さらに、コミットとGitHubへの送信も別です。ローカルに記録した後、共有先へ送る操作が push です。まずは最初のコミットを試すと、区別がつかみやすくなります。

ブランチ

履歴の流れを分け、別の変更を進めるための仕組みです。新機能用、修正用など、目的ごとに作業を分けるときに使います。

たとえば公開用の main とは別のブランチで見出しを直し、確認後に統合します。この統合をマージと呼びます。

注意したいのは、ブランチを作るだけで未保存・未コミットの編集が別の箱へ隔離されるわけではないことです。切り替え時に変更が持ち越される場合や、切り替えが止められる場合があります。作業前後の git status で状態を確認しましょう。ブランチとマージで具体例を追えます。

差分

変更前と変更後の違いです。コードでは、追加・削除された行などを並べて表示します。英語ではdiffと呼ばれます。

AIの「修正しました」という説明を読むだけでなく、「実際にはどのファイルの何行が変わったのか」を確かめるために使います。

git diff は通常、まだステージングしていない変更を表示します。ステージング済みの変更は git diff --staged、未追跡の新規ファイルは git status で存在を確認して内容を開きます。「差分が空だから変更ゼロ」と早合点しないようにしましょう。Git公式のdiff説明

Pull Request（プルリクエスト）

GitHubなどで使う、変更を別のブランチへ取り込むための提案です。PRと略されます。

差分を見せて「この修正を入れてよいですか」と相談し、レビューや自動テストを経てマージする流れです。レビューは、他の人や自分が変更の内容を確かめること。

PRを作っただけでは、通常、変更はまだ統合されていません。また、PRを作る操作と git pull は別物です。pull はリモートの変更を取り込むGitの操作です。GitHubのPR解説

動作確認に関する言葉

ビルド

コードを、実行や公開に適した形へまとめる作業です。言語や仕組みにより、コンパイル、複数ファイルのまとめ直し、静的ページの生成など、行う内容は違います。

このサイトのような静的サイトでは、記事や共通レイアウトから公開用のHTMLなどを作ります。

「ビルド成功」はうれしい知らせですが、ボタンが正しい場所へ移動する、説明文が正しい、といったことまで保証しません。次のテストと分けて考えましょう。

テスト

期待した動きと、実際の結果を比べる確認です。人が画面を操作する方法も、コードで自動実行する方法もあります。

足し算の関数なら「2と3を渡すと5になる」が一つのテストです。ただ起動してエラーがなかった、だけでは期待どおりか判断できません。

普通の入力に加え、0、空欄、上限ぴったりなども確認します。どんな値を試すかはAIコードのチェックリストで練習できます。

サンドボックス

プログラムが触れるファイルやネットワークなどの範囲を制限した環境です。失敗しても影響が広がりにくくするために使います。

AIの編集を練習用フォルダ内に限定する、といった使い方があります。ただし制限の内容は製品や設定によって違います。「サンドボックス」という名前だけで、外部送信も削除もすべて防げるとは限りません。

操作できる範囲の制限と、「この操作を許可しますか」という承認確認も別の仕組みです。確認画面があるだけで、コードの動作が正しいと保証されるわけではありません。

AIやサービス連携に関する言葉

AIエージェント

目標に向けて、情報を集め、道具を使い、結果を確かめながら作業を進めるAIの仕組みです。コーディング用なら、ファイル検索、編集、テスト実行などを組み合わせます。

チャットでコードを提案するだけの場合と、実際のファイルを書き換える場合では、失敗したときの影響が違います。

「調べるだけ」「編集まで」「公開まで」のどこを任せるかを分けましょう。エージェントという言葉自体には、何でも自動で許可されるという意味はありません。

API

プログラムから、別の機能を決められた方法で使うための窓口です。Application Programming Interfaceの略です。

たとえば天気サービスのAPIへ地域を指定すると、気温などのデータを受け取り、自分のアプリに表示できます。人がWeb画面をクリックする代わりに、プログラムが指定の形式でやり取りするイメージです。

使える操作、入力形式、回数や料金の条件はAPIごとに違います。Webサービス間の通信だけでなく、OSやライブラリが提供する窓口にもAPIという言葉を使います。

APIキー

APIへのアクセス元や利用するプロジェクトなどを識別する文字列です。サービスによって、権限確認や利用料金のひも付けにも使われます。

特に、AIサービスなどの秘密のAPIキーは、他人に使われると不正利用や請求につながるおそれがあります。公開記事、GitHub、スクリーンショットへ載せないでください。公開用のキーを別に用意するサービスもありますが、秘密かどうか不明なら公開しないのが基本です。

もし秘密のキーが漏れたら、文字を消すだけでなく、発行元で無効化・再発行などの対応をします。履歴やコピーが残っている可能性があるためです。GitHubの秘密情報流出への対応

環境変数

名前と値の組を、プログラムが動く環境から渡す仕組みです。APIキーや接続先、実行モードなどをコードから分けて指定するときに使います。

例として「接続先」という設定を、開発用と公開用で変える場面を考えてください。コードを書き直さず、動かす環境側の値を変えられるのが便利な点です。

ただし、環境変数はそれ自体が暗号化された保管庫ではありません。ログへ出力したり、ブラウザへ配るコードに埋め込んだりすれば漏れます。.env という設定ファイルも、公開しないための管理が必要です。

確認問題：保存したら公開される？

次の3つを、一言で説明してみましょう。

ファイルを保存することと、コミットすることの違い
コミットすることと、pushすることの違い
ビルドが成功することと、テストで動作を確認することの違い

模範解答と解説

保存は現在のファイルを残すこと、コミットは選んだ状態をGitの履歴へ記録することです。どちらか一方だけで両方が済むわけではありません。
コミットはローカルにも作れます。pushはそのコミットを共有先へ送る操作です。さらに公開サイトの反映には、そのサイトの配信手順が関係します。
ビルドは実行・公開用の形を作る作業、テストは期待する結果との比較です。ページが生成できても、リンク先を間違えていることはあります。

似た言葉を使い分けられると、「どこまではできていて、どこで止まっているか」が伝えやすくなります。全部暗記するより、この違いから慣れていきましょう。