プログラムが動く仕組みを整理し、テスト観点・前提条件・制約条件を加えることで、Codex が期待通りの安全なプログラムを生成できるようになる。
目次
安全なプログラムとは
第1章で作ったプログラムは「動く」という点では問題ない。しかし、他人に渡して実際に使ってもらうには、それだけでは不十分だ。プログラムの安全性には、次のような側面がある。
これらを Codex に守らせるには、プロンプトでその条件を明示的に伝えなければならない。「よきに計らえ」では、Codex は最低限動くだけのコードを生成するにとどまる。
これらを Codex に守らせるには、プロンプトでその条件を明示的に伝えなければならない。「よきに計らえ」では、Codex は最低限動くだけのコードを生成するにとどまる。
| 観点 | 内容 |
|---|---|
| 機能の正しさ | 意図した通りに動作し、バグがないこと |
| 堅牢性 | 想定外の入力や操作をしてもクラッシュしないこと |
| セキュリティ | 個人情報や機密データを外部に漏らさないこと |
| ライセンス遵守 | 利用するライブラリのライセンス条件を守っていること |
| 動作環境への適合 | 想定するブラウザやデバイスで正しく動くこと |
プログラムが動く仕組み
プログラムが動く仕組み
プログラムは、人間が「# 目標」を与えるところから始まる。目標とは、プログラムを使って解決したい課題や達成したいことだ。その目標を実現するために、プログラムは次の5つの要素で動く。
| 要素 | 具体例 | 説明 |
|---|---|---|
| ## 入力 | キーボード、マウス | ユーザーからデータや指示を受け取る |
| ## 処理 | CPU・GPU・メモリ | マザーボード上のCPUやGPUがデータを計算・加工する |
| ## 通信 | インターネット、LAN | ネットワークを介してPC外部とデータを送受信する |
| ## 出力 | 画面、プリンタ | 処理結果をユーザーに見せる |
| ## 記録 | SSD、HDD、クラウド | データをファイルやデータベースに保存する |
プログラム仕様書には、この5要素それぞれについて「何をするか」を具体的に書く。たとえば「## 入力」なら「ユーザーはマウスで石を置く」、「## 通信」なら「なし（インターネットとの通信は行わない）」といった具合だ。要素ごとに明示することで、Codex は何を実装すべきかを正確に把握できる。
テスト観点と例外・エラー処理
テスト観点・合格条件と例外・エラー処理
「# 目標」を達成したかどうかを確認するために、「# テスト観点・合格条件」が必要だ。テスト観点とは「何を確認するか」、合格条件とは「どうなれば合格とみなすか」を具体的に示したものだ。たとえば「Codexが5回プレイし、最後まで正常に動作すれば合格」のように書く。
この条件を仕様書に含めることで、Codex はプログラムを生成したあとにテストまで自動で実行し、結果をチャットに表示する。
また、「## 処理」などの途中で想定外の事態が発生したときの振る舞いを「## 例外・エラー処理」として記述する。
エラーと例外は似た概念だが、意味が異なる。
この条件を仕様書に含めることで、Codex はプログラムを生成したあとにテストまで自動で実行し、結果をチャットに表示する。
また、「## 処理」などの途中で想定外の事態が発生したときの振る舞いを「## 例外・エラー処理」として記述する。
エラーと例外は似た概念だが、意味が異なる。
| 用語 | 意味 | 例 |
|---|---|---|
| エラー | プログラムの実行を継続できない致命的な問題 | メモリ不足、無限ループ、システムのクラッシュ |
| 例外 | 想定外だが処理を続けられる可能性がある問題 | ファイルが見つからない、ネットワーク接続が切れた |
仕様書には「無限ループに陥ったり、システム・エラーが出たときは、画面にエラー情報を表示して終了すること」のように、エラーや例外が発生したときに何を表示してどう終了するかを具体的に書く。これを省くと、Codex はエラー時の処理を省略したプログラムを生成することがある。
前提条件と制約条件
前提条件と制約条件
「# 目標」の達成に直接は関係しないが、決めておく必要がある条件を「非機能要件」と呼ぶ。本講座では、これを次の2つに分けて記述する。
「# 前提条件」には、動作させるブラウザの種類、ファイル構成のルール、コーディング規約（本講座では「Airbnb JavaScript Style Guide」を採用する）などを書く。「# 制約条件」には、外部との通信禁止、使用できる外部ライブラリのURLを限定するといった、セキュリティや法的リスクを避けるための条件を書く。
これらを省いた場合、Codex は任意のCDNからライブラリを読み込むコードを生成したり、意図せずユーザーのデータを外部に送信するコードを書いたりする可能性がある。
「# 前提条件」には、動作させるブラウザの種類、ファイル構成のルール、コーディング規約（本講座では「Airbnb JavaScript Style Guide」を採用する）などを書く。「# 制約条件」には、外部との通信禁止、使用できる外部ライブラリのURLを限定するといった、セキュリティや法的リスクを避けるための条件を書く。
これらを省いた場合、Codex は任意のCDNからライブラリを読み込むコードを生成したり、意図せずユーザーのデータを外部に送信するコードを書いたりする可能性がある。
| 区分 | 内容 | 例 |
|---|---|---|
| # 前提条件 | 目標を達成するための動作環境・開発ルールなど | 「JavaScriptを使った1本のファイルにすること」「スマホでも動作すること」 |
| # 制約条件 | セキュリティや著作権など安全性を担保するための条件 | 「インターネットとのデータ送受信は行わないこと」「MITライセンスに違反しないこと」 |
オセロゲームのプログラム仕様書
ここまで説明した要素をすべて盛り込んだ、オセロゲームのプログラム仕様書を示す。これが Codex に渡すプロンプトそのものになる。
プログラム仕様書（プロンプト）
# 目標 画面上でコンピュータと対戦するオセロゲームを作る。
# プログラム・ファイル名 othello.html
# プロジェクト・フォルダ作成 - プログラム・ファイル名の拡張子を除いた主ファイル名と同じ名前のサブフォルダを作成し、以降の作業はサブフォルダで行う。 - すでにサブフォルダがあれば、そのサブフォルダに移動して以降の作業を進める。
## 入力 - ユーザーはマウス入力で石を置く。 - ユーザーが「降参」ボタンをクリックしたらゲーム終了。
## 処理 1）ゲーム開始時に、サイコロを振って先攻・後攻を決める。 2）ユーザーが石を置いたら、盤面にある石の状態を更新する。 3）コンピュータは勝利することを目標に石を置き、盤面にある石の状態を更新する。 4）ユーザーの次の入力を待つ。
## 通信 なし。
## 出力 - プログラム上部にタイトル「オセロゲーム」、バージョン番号、製作者「(c)sturio pahoo Powerd by Codex」と記載する。 - 画面に盤面の状態を見やすい色で表示する。 - 石は白色・黒色にする。 - 盤面は緑系の配色にする。 - ゲーム終了後に、盤面の状態はそのままで、勝者と敗者を画面に表示する。
## 例外・エラー処理 - 無限ループに陥ったり、システム・エラーが出たときは、画面にエラー情報を表示して終了すること。
## 記録 なし。
# テスト観点・合格条件 - Codexが5回プレイし、最後まで正常に動作すれば合格。テスト結果をチャットに表示する。 - すべての処理が含まれていること。 - 前提条件、制約条件が守られていること。
# 前提条件 - 仕様で分からないことがあれば、ユーザーに質問すること。 - JavaScriptを使った1本のプログラム・ファイルにすること。 - クライアントPCのブラウザ（OSやブラウザの種類は問わない）で動作すること。 - スマホでも利用できること。 - httpサーバなどやNode.jsなどサーバ技術は使わず、ブラウザの機能で完結すること。 - コーディングは「Airbnb JavaScript Style Guide」にのっとること。
# 制約条件 - インターネットとのデータ送受信は行わないこと。 - 外部ライブラリを使用する場合は、下記のサイトに限定すること https://cdn.jsdelivr.net/ https://cdnjs.cloudflare.com/ https://ajax.googleapis.com/ https://code.jquery.com/ https://ajax.aspnetcdn.com/ - プログラムがMIT Licenseに違反していないこと。
このプログラム仕様書を Codex に渡すと、先攻・後攻をサイコロで決める機能、降参ボタン、盤面の配色、エラー時の画面表示まで含んだプログラムが生成される。Codex はテスト観点・合格条件に従って自動テストも実行し、結果をチャットに表示する。
ファイル名とプロジェクト・フォルダ
プロンプトに、「# ファイル名」「# プロジェクト・フォルダ作成」が加わっている。これについて説明しよう。
まず「# ファイル名」だが、コンピュータでは、プログラムはもちろん、WORDの文書ファイルやExcelファイル、その他、ありとあらゆるデータを保管・識別するのにファイル名が必要だ。本講座で作るプログラムは1つのHTMLファイル（ホームページでよく見かけるコンテンツと同じ）なので、1つだけファイル名を指定する。ファイル名は日本語でもかまわないのだが、プログラミングの慣習に倣って、英語で記述する。
英語が苦手な方もいるかもしれないが、Codex に翻訳してもらえばいい。
次に「# プロジェクト・フォルダ作成」だが、まず、Windows, macOS, Linux, iOS, Androidといった現行OSにはディレクトリまたはフォルダと呼ばれるファイルを格納するための構造がある。
たとえば Windows の場合、下記のようなディレクトリ構造になっている。
まず「# ファイル名」だが、コンピュータでは、プログラムはもちろん、WORDの文書ファイルやExcelファイル、その他、ありとあらゆるデータを保管・識別するのにファイル名が必要だ。本講座で作るプログラムは1つのHTMLファイル（ホームページでよく見かけるコンテンツと同じ）なので、1つだけファイル名を指定する。ファイル名は日本語でもかまわないのだが、プログラミングの慣習に倣って、英語で記述する。
英語が苦手な方もいるかもしれないが、Codex に翻訳してもらえばいい。
次に「# プロジェクト・フォルダ作成」だが、まず、Windows, macOS, Linux, iOS, Androidといった現行OSにはディレクトリまたはフォルダと呼ばれるファイルを格納するための構造がある。
たとえば Windows の場合、下記のようなディレクトリ構造になっている。
Codex のプロジェクトで、最初に "プログラム開発" という名前を指定したが、これは "Documents" フォルダの下に作成される。
これから幾つかのプログラムを作っていくのだが、1つのプログラムを作ることをプロジェクトと呼ぶことにする。
プロジェクト には、プログラム・ファイル（ここでは "othello.html"）のほか、次項で作成する簡易取扱説明書や、プロンプトそのものを格納する。
そこで、管理がしやすいように、"プログラム開発" フォルダの下に、プロジェクトごとにフォルダを作成することにする。フォルダ名は、プログラムファイルの主ファイル名（ここでは "othello"）にする。
このプロジェクト・フォルダを作成する指示を書いたのが、「# プロジェクト・フォルダ作成」である。
これから幾つかのプログラムを作っていくのだが、1つのプログラムを作ることをプロジェクトと呼ぶことにする。
プロジェクト には、プログラム・ファイル（ここでは "othello.html"）のほか、次項で作成する簡易取扱説明書や、プロンプトそのものを格納する。
そこで、管理がしやすいように、"プログラム開発" フォルダの下に、プロジェクトごとにフォルダを作成することにする。フォルダ名は、プログラムファイルの主ファイル名（ここでは "othello"）にする。
このプロジェクト・フォルダを作成する指示を書いたのが、「# プロジェクト・フォルダ作成」である。
マークダウン記法
プログラム仕様書は「マークダウン記法」で書く。マークダウンとは、プレーンテキストに簡単な記号を加えることで、見出し・箇条書き・番号付きリストなどの構造を表現する書き方だ。Codex を含む多くのAIツールがマークダウンを理解し、構造に従って処理を行う。
| 記法 | 意味 | 使用例 |
|---|---|---|
| # テキスト | 見出し（レベル1） | # 目標 |
| ## テキスト | 見出し（レベル2） | ## 入力 |
| ### テキスト | 見出し（レベル3） | ### 詳細 |
| - テキスト | 箇条書き（順序なし） | - マウスで石を置く |
| 1) テキスト | 番号付きリスト | 1）ゲーム開始時に... |
「#」の数が増えるほど見出しのレベルが下がる。本講座のプログラム仕様書では、「# 目標」「# テスト観点・合格条件」「# 前提条件」「# 制約条件」を大項目（レベル1）、「## 入力」「## 処理」などを小項目（レベル2）として使い分けている。
テスト観点・合格条件、前提条件、制約条件の意味
「# テスト観点・合格条件」「# 前提条件」「# 制約条件」という言葉は、初めて見るかもしれない。それぞれについて説明しよう。
| 項目 | 意味 | プログラム仕様書での例 |
|---|---|---|
| # テスト観点・合格条件 | 「目標を達成できているか」を確かめるための基準。何を確認し、どうなれば合格かを書く。 | 「Codexが5回プレイして最後まで動作すれば合格」 |
| # 前提条件 | プログラムを動かすために必要な環境やルール。これを守らないと目標を達成できない。 | 「スマホでも動作すること」「1ファイルにまとめること」 |
| # 制約条件 | 安全性・法的リスクを避けるために守らなければならない制限。違反すると問題が生じる。 | 「インターネットにデータを送らないこと」「MITライセンスに違反しないこと」 |
料理に例えると、「# 目標」はレシピの完成形（「カレーを作る」）、「# テスト観点・合格条件」は試食して合格かどうか判断する基準（「辛さがちょうどよいこと」）、「# 前提条件」は調理環境（「IHコンロを使うこと」）、「# 制約条件」は食材の制限（「アレルギー食材は使わないこと」）にあたる。
仕様書通りにいかないとき
これだけ詳しいプログラム仕様書を書いても、期待通りのプログラムができないことがある。その場合は、不具合のある箇所をプロンプトで具体的に伝え、修正を指示する。
修正指示の例
ゲーム終了後に「新しいゲームを始める」ボタンが表示されない。追加してほしい。
不具合の修正は、何度でも繰り返すことができる。「どこが」「どう動かない」「どうなってほしい」の3点を具体的に書くと、Codex は的確な修正を行いやすい。逆に「おかしい」「直して」だけでは、Codex が問題箇所を特定できず、意図しない変更が加わることがある。
詳説：前提条件と制約条件
本項は読まなくても差し支えない。プログラムの安全性を担保するため、「# 前提条件」「# 制約条件」には専門的な内容が書かれているので、ここで補足しておく。
# 前提条件
# 前提条件
- - 仕様で分からないことがあれば、ユーザーに質問すること。
- Codex がプログラム作りに必要な情報を仕様から読み取れなかったときは、自己判断せずユーザーに質問しろという指示である。
- - JavaScriptを使った1本のプログラム・ファイルにすること。
- 1本にまとまっていた方がプログラムを配布しやすいので、このような指示をする。ホームページを作ったことがある方はご存じのように、実際のHTMLファイルは、JavaScriptを別ファイル（拡張子.js）に分けたり、画面のレイアウトなどを指定するスタイルシートも別ファイル（拡張子.css）に分けることが一般的だが、それを行わないようにするという指示でもある。
- - クライアントPCのブラウザ（OSやブラウザの種類は問わない）で動作すること。
- これは文字通りの意味。
- - スマホでも利用できること。
- これは文字通りの意味。
- - httpサーバなどやNode.jsなどサーバ技術は使わず、ブラウザの機能で完結すること。
- JavaScriptはHTMLファイルとともに、httpサーバを経由してインターネット上で動かすときに使うのが一般的だが、今回はインターネットがなくても動くように指示している。Node.jsというのは、JavaScriptをサーバ側で動かすための技術であるが、これも使わないよう指示する。
- - コーディングは「Airbnb JavaScript Style Guide」にのっとること。
- プログラムにもお作法があり、これをコーディング規約と呼ぶ。もしJavaScriptプログラマが読むことを考えて、ここではJavaScriptに標準的なコーディング規約である「Airbnb JavaScript Style Guide」を指定している。
- - インターネットとのデータ送受信は行わないこと。
- 情報漏洩を避けるためにインターネット通信は行わないよう指示する。
- - 外部ライブラリを使用する場合は、下記のサイトに限定すること。
- 今回は使わなかったが、JavaScriptの機能を拡張する多くの外部ライブラリがオープンソースの形で出回っている。ただ、悪意をもって改竄されたものがある可能性があるので、外部ライブラリは信頼のおける配布元から取得するよう指示する。
- - プログラムがMIT Licenseに違反していないこと。
- 著作権を侵害していないことを確認させる指示。「MITライセンス」は、オープンソースであるかどうかに関わらず再利用・再配布を行えるライセンス形態である。
参考サイト
- Codex：OpenAI
- Airbnb JavaScript Style Guide()：javascript-style-guide
- Markdown Guide：Markdown公式ガイド
- JavaScriptによるプログラミング入門：ぱふぅ家のホームページ
（この項おわり）
Codex に安全なプログラムを作ってもらうには、プロンプトで必要な情報を正確に伝えることが大切だ。本項では、あらゆるプログラム開発に使えるプロンプトのひな形――本講座ではこれを「プログラム仕様書」と呼ぶ――を作る方法を学ぶ。