【IT知識ゼロからOK】プログラムとAPIの基本 ― 生成AI時代のアーキテクチャ超入門・基礎編

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ITの基礎知識」編・第4弾として、プログラムとAPIの基本を解説する記事です。

基礎編の第1弾では、注文に応じて処理をする部分を「キッチン」と呼びました。今回はそのキッチンの中身、つまりプログラムの話です。プログラムとは何か、プログラミング言語やフレームワークという言葉は何を指しているのか、そして本編で最頻出の単語の一つであるAPIとは何か。このあたりを、引き続きレストランの例えで押さえていきます。

そもそもプログラムとは何か

プログラムとは、ざっくり言えば「コンピュータに向けて書いた手順書」のことです。料理で言えばレシピですね。

ただし、人間向けのレシピと決定的に違う点が一つ有ります。それは曖昧さが一切許されないことです。人間向けのレシピなら「塩少々」「きつね色になるまで」で通じますが、コンピュータは書かれたことを書かれた通りにしか実行してくれません。「塩を1.2グラム入れる」「180秒加熱する」のように、全ての手順を厳密に書き切る必要が有ります。

逆に言えば、厳密に書きさえすれば、コンピュータはその手順を1秒間に何億回でも、飽きずに間違えずに実行してくれます。注文が来るたびに在庫を確認して、値段を計算して、台帳に記録する。こうした定型作業を超高速で回し続けられるのが、プログラムの本質的な価値なのです。

プログラミング言語 ― 手順書を書くための言語

その手順書を書くための言語がプログラミング言語です。

本編ではTypeScript（タイプスクリプト）、Python（パイソン）、Java（ジャバ）といった名前が出てきますが、これらは全部プログラミング言語の名前です。日本語や英語のような自然言語と同じで、言語ごとに得意分野や使われる場面が違います。ブラウザ側の画面の動きが得意な言語、AIやデータ分析に強い言語、大企業の業務システムで長年使われてきた言語、といった具合です。

本編の「プログラミング言語選定」という記事は、要するに「うちのお店の手順書は何語で書くか」を決める話です。書ける料理人（エンジニア）を雇いやすい言語かどうか、というのが選定の大きな決め手になる、という話が出てきますが、手順書が特殊な言語で書かれていたら読める人を探すのが大変になる、と考えれば納得しやすいと思います。

フレームワーク ― 業務用キッチンセット

プログラミング言語の次によく出てくるのがフレームワークという言葉です。

フレームワークとは、ざっくり言えば「よくある作業が最初から組み込まれた、業務用のキッチンセット」です。

考えてみると、Webサービスの処理には、どのお店でも共通する部分がかなり有ります。注文を受け付ける、会員かどうかを確認する、結果を画面の形に整えて返す・・・こうした定番作業を毎回ゼロから手順書に書くのは、キッチンを毎回ゼロから組み立てるようなもので、明らかに無駄ですよね。

なので、定番作業を最初からセットにした「型」が用意されていて、開発者は自分のお店ならではの部分だけを書き足せば良いようになっています。これがフレームワークです。本編に出てくるNext.js（ネクストジェイエス）やRails（レイルズ）といった名前は、このキッチンセットの製品名です。

フレームワークと似た言葉にライブラリというものも有ります。こちらは「特定の作業に使う道具の詰め合わせ」で、キッチンセットではなく単品の調理器具のイメージです。日付の計算だけをやってくれる道具、グラフの描画だけをやってくれる道具、といった具合ですね。フレームワークが「キッチンの構造ごと決めてしまうもの」なのに対して、ライブラリは「必要なときに棚から取り出して使うもの」という違いが有ります。本編ではどちらも頻出しますが、この粒度の違いだけ掴んでおけば十分です。

APIとは ― 他のお店への注文窓口

さて、今回の記事で一番覚えて帰って欲しいのがAPI（エーピーアイ）です。本編では、おそらく最も頻繁に登場する単語の一つです。

APIとは、ざっくり言えば「プログラム同士が注文をやり取りするための窓口」のことです。

第1弾で、ブラウザがサーバーに注文（リクエスト）を出すという話をしました。実はこの注文のやり取りは、人間対お店だけではなく、お店対お店の間でも行われています。例えるなら出前や仕入れです。自分のお店で全部作らずに、専門店に頼んでしまうわけですね。

例えばネット通販サイトを作るとき、クレジットカード決済の仕組みを自分で作るのは大変ですし、危険でも有ります。なので、決済の専門店に「この金額を決済してください」とプログラムから注文して、結果だけ受け取ります。地図の表示なら地図の専門店へ、メールの送信ならメール配信の専門店へ。この注文の窓口と書式を定めたものがAPIです。

現代のWebサービスは、実はこうした「専門店への出前注文」の組み合わせで出来ています。全部を自分のキッチンで作っているお店は、ほとんど有りません。本編で「API連携」「外部APIを呼ぶ」という表現が出てきたら、「ああ、専門店に注文を出しているんだな」と読み替えてもらえれば大丈夫です。

自分のお店の中にも窓口がある

APIは外部への注文だけではなく、自分のお店の中でも使われています。

第1弾で説明した通り、お店の中はホール係（フロントエンド）とキッチン（バックエンド）に分業されています。このホール係からキッチンへの注文の受け渡しにも、APIという形で窓口と書式が決められているのです。「注文はこの伝票の書式で書く」と決まっているからこそ、ホール係とキッチンの担当者が別の人でも、連携ミスなく回せるわけですね。

本編に「API設計」という記事が有りますが、あれは要するに「伝票の書式をどう決めれば、後々まで揉めずに済むか」を論じている記事です。書式が雑に決められたお店は、注文の行き違いが頻発して大変なことになる・・・という想像がつけば、あの記事の重要性も伝わるかと思います。

プログラムのよくある勘違い

ここで、プログラミングの世界に対する初心者の方の勘違いをいくつか整理しておきます。

まず「プログラマーは書き方を全部暗記している」という誤解です。実際のところ、プロの開発者も調べながら書くのが当たり前で、細かい書き方は覚えていないことの方が多いです。料理人が全レシピを暗記していないのと同じですね。そして今は、生成AIが手順書の下書きをかなりの精度で書いてくれる時代になりました。だからこそ本シリーズは、「書き方」よりも「何をどう作るかの判断」の方に紙幅を割いています。

次に「最強のプログラミング言語がどれか決まっている」という誤解です。残念ながら（と言うべきか幸いにも、ですが）万能の言語は存在せず、得意分野と使う場面で選び分けるのが実態です。和食の名店とフレンチの名店に優劣を付けられないのと同じで、本編の言語選定の記事も「どれが最強か」ではなく「自分のお店にはどれが合うか」という組み立てになっています。

そして「APIは高度で特別な技術」という身構えです。ここまで読んでいただいた通り、APIの正味の中身は「注文の窓口と伝票の書式の取り決め」であって、仕組み自体はとても素朴なものです。横文字の略語というだけで難しく感じてしまいますが（気持ちはとてもよく分かります・・・）、本編でAPIという文字を見かけたら、身構えずに「窓口の話ね」と流し読みしてもらって大丈夫です。

本編用語との対応表

今回の例えと、本編で実際に使われる用語の対応を一覧にしておきます。

本編との繋がり

プログラムとAPIの話は、本編では「ソフトウェアアーキテクチャ」（手順書全体の骨格や言語の話）、「アプリケーションアーキテクチャ」（手順書の書き方のルールの話）、「フロントエンドアーキテクチャ」（ホール係側の話）の3カテゴリに分かれて扱われています。

ソフトウェアアーキテクチャ概要 ― 宗派の多い領域の歩き方 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-software-overview/

この記事に関連する記事

まとめ

本記事はプログラムとAPIの基本について、レシピと出前の例えで解説しました。如何だったでしょうか。

プログラムは曖昧さゼロの手順書、フレームワークは定番作業込みの業務用キッチンセット、そしてAPIはお店同士が注文をやり取りする窓口です。特にAPIは本編のあらゆる場所に顔を出しますので、「専門店への出前注文」のイメージだけでも持ち帰ってもらえると嬉しいです。

次回の基礎編では、お店の防犯にあたる「セキュリティと認証の基本」を解説していく予定です。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。