先生と生徒の会話形式で理解しよう

生徒

「COBOLのプログラムを読んでいると、アスタリスクがついた日本語の説明がたくさんあります。これって何のためにあるんですか？」

先生

「それは『コメント』と呼ばれるものです。コンピュータは無視しますが、人間がプログラムの内容を理解するためにとても重要な役割を果たします。」

生徒

「自分のメモみたいに好き勝手書いてもいいんでしょうか？」

先生

「いえ、仕事で使うプログラムには『コメントポリシー』というルールがあります。どこに何を書くべきか、その基本を学んでいきましょう！」

1. コメントとは？プログラムの中の「注釈」の基本

プログラミング未経験の方にとって、画面に並ぶ英語や数字の羅列は呪文のように見えるかもしれません。しかし、COBOLのプログラムには、その呪文が何をしているのかを日本語で説明する仕組みがあります。それがコメント（注釈）です。

コンピュータは、プログラムを実行するときにこのコメント部分を完全に読み飛ばします。つまり、コメントをどれだけたくさん書いても、プログラムの動きが遅くなったり、間違いが起きたりすることはありません。コメントは、あくまで「未来の自分」や「一緒に働く仲間」に向けたお手紙のようなものです。

パソコンを触ったことがない方でも、料理のレシピをイメージしてみてください。材料や手順の横に「ここは焦げやすいので弱火で」とか「玉ねぎは飴色になるまで炒めるとコクが出る」といったアドバイスが書いてあることがありますよね。それがプログラムにおけるコメントです。手順（コード）だけでは伝わらない「意図」を書き残すことが、コメントの最大の目的です。

2. COBOLでのコメントの書き方（アスタリスクの使い方）

COBOLでコメントを書くには、決まった場所があります。一般的に「固定形式」と呼ばれる書き方では、行の左から数えて7番目の列にアスタリスク（*）を記述します。これが「この行はコメントですよ」という合図になります。

この7列目にアスタリスクを入れると、その行の8列目以降に何を書いたとしても、コンピュータは無視してくれます。また、行全体をハイフン（-）で区切って見やすくしたり、スラッシュ（/）を使って改ページを指定したりすることもありますが、初心者のうちはまず「7列目のアスタリスク」を覚えましょう。

注意点として、1列目から6列目までは行番号などを入れる場所なので、そこにアスタリスクを書いてはいけません。しっかり7番目のマス目に書く。この丁寧なルールこそが、長年日本の金融や社会インフラを支えてきたCOBOLの伝統的な作法なのです。


000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. SAMPLE01.
* これはコメント行です。ここには日本語で説明が書けます。
* プログラムのタイトルや作成日を書くのが一般的です。
000300 PROCEDURE DIVISION.

3. プログラムの先頭に書くべき「見出しコメント」

コメントポリシーの基本として、プログラムの最初には必ず見出しコメント（ヘッダーコメント）を書きます。これは、そのプログラムが「何のためのものか」を宣言する名札のような役割を果たします。

見出しには以下の情報を入れるのが標準的です。

プログラム名（何をするプログラムか）
作成者名（誰が作ったか）
作成日（いつ作ったか）
修正履歴（いつ、誰が、どこを直したか）

これらが書いていないと、後で不具合が見つかったときに「誰に聞けばいいのか」「いつからおかしいのか」が分からず、調査に膨大な時間がかかってしまいます。事務処理を得意とするCOBOLだからこそ、こうした事務的な管理情報が非常に重視されるのです。


*****************************************************************
* プログラム名：売上集計処理
* 作成者      ：山田 太郎
* 作成日      ：2026/03/10
* 内容説明    ：月間の売上データを読み込み、支店ごとに集計する
*****************************************************************

4. 処理の区切りを明確にする「セクションコメント」

プログラムは、上から下まで一気に書かれていると、どこからどこまでが一つのまとまりなのか判別しにくくなります。そこで、大きな処理の区切りごとにコメントを入れて、見出しをつけるセクションコメントを活用します。

例えば、「データの読み込み準備」「計算処理」「結果の出力」「終了処理」といった具合に、本の内容で言う「章」や「節」のように整理します。こうすることで、後から「計算のロジックだけ確認したい」と思ったときに、目印となるコメントを探すだけで目的の場所にたどり着けるようになります。

可読性（読みやすさ）を高めるためには、ただ文字を書くだけでなく、ハイフンやアスタリスクを並べて飾り枠を作ることもあります。視覚的に「ここから新しい話が始まりますよ」とアピールすることが、親切なコメントポリシーのポイントです。


*---------------------------------------------------------------*
* データ入力セクション
*---------------------------------------------------------------*
           OPEN INPUT SALES-FILE.
           READ SALES-FILE AT END SET END-OF-FILE TO TRUE.

5. 「なぜ」を書く！コードの意図を説明するコメント

初心者がやってしまいがちな失敗に、「コードをそのまま日本語に訳しただけのコメント」を書いてしまうことがあります。例えば、ADD 1 TO COUNT の横に「カウントに1を足す」と書くようなケースです。これでは、コードを読めばわかることを二回書いているだけで、あまり意味がありません。

本当に書くべきなのは、「なぜ」その処理が必要なのかという理由です。「消費税の計算で小数点以下を切り捨てるため」や「不正なデータが混じった場合にエラーとして除外するため」といった背景こそが、後から読む人にとって価値のある情報になります。

コードは「どのように（How）」動くかを示しますが、コメントは「なぜ（Why）」それをするのかを語ります。未来の自分が、なぜこの複雑な計算式を書いたのかを忘れてしまっても、コメントがあれば当時の自分の思考を辿ることができるのです。これが、長期にわたって運用されるシステムにおける「保守性」の向上に繋がります。

6. データの定義に添える「項目説明コメント」

COBOLの最大の特徴は、データ構造の定義（DATA DIVISION）が非常に充実していることです。ここで定義される変数（データの入れ物）の一つひとつに、それが何を意味するのかをコメントで添えるのがベストプラクティスです。

例えば、WK-PRICE という名前の変数があったとき、それが「税抜き価格」なのか「税込み価格」なのか、あるいは「割引前の価格」なのかは名前だけでは判断しきれないことがあります。横に一言「※税込みの販売価格を格納」と書いてあるだけで、誤解による計算ミスを未然に防ぐことができます。

パソコン初心者の方には、これは「引き出しにラベルを貼る」作業だと思ってください。「文房具」とだけ書かれた引き出しより、「ハサミとホッチキス」と細かく書かれている方が、迷わず目的のものを手に取れますよね。データの定義にコメントを添えることは、プログラムという大きなタンスを整理整頓する作業なのです。これにより、誰が見ても使いやすいデータ構造が保たれます。


01  WK-AREA.
    05  WK-TOTAL-PRICE  PIC 9(08).  *> 合計金額（税込み）
    05  WK-CUST-COUNT   PIC 9(04).  *> 来客数（人単位）
    05  WK-RESERVE      PIC X(10).  *> 予備領域

7. メンテナンスを助ける「修正履歴コメント」

長年使われているCOBOLプログラムには、何度も修正が加えられます。いつ、どのような理由で、誰が、どの行を変更したのかを記録しておく修正履歴コメントは、エンジニアにとっての命綱です。一般的には、修正した箇所の行末に、その時の案件番号や修正日付を短い記号で書き残します。

例えば、消費税率が変わったときの修正箇所に「@202410-TAX」といった印をつけておきます。すると、後で「最近計算がおかしくなったぞ」となったときに、その印を検索するだけで、最近変更された怪しい場所をすぐに特定できます。古いコードを消さずにあえてコメントとして残しておく「旧コードのコメントアウト」も、万が一のときに元に戻すために行われることがあります。

これは、歴史の教科書にある「年表」のようなものです。どのような経緯で今のプログラムの形になったのかを知ることで、安易な変更による先祖返り（一度直したはずの不具合が復活すること）や二次災害を防ぐことができます。慎重さが求められる基幹業務システムにおいて、修正履歴は欠かせない情報です。

8. 実行結果のログとコメントの相乗効果

プログラムが動いたときに出力される「実行結果（ログ）」も、実はコメントの考え方に通じるものがあります。画面に表示されるメッセージに、コメントで書いたような「処理の意図」が含まれていれば、エラーが起きたときの解決スピードが格段に上がります。

例えば、プログラムの中でコメントとして「ここでファイルを開く」と書いているなら、実行時にも「ファイルオープン開始」と表示させるようにします。こうすることで、万が一プログラムが止まってしまったときに、ソースコードのコメントと、実行結果のログを照らし合わせることができます。「あ、コメントにある『データチェック』のところで止まっているな」と、すぐに原因の切り分けができるのです。

このように、プログラムの内側にあるコメントと、外側に出るメッセージを連動させることで、初心者の方でもトラブルに対して冷静に対応できるようになります。可読性は、ただコードが読みやすいだけでなく、動いているときの様子が透けて見える状態を指すのです。


    --- 処理開始：2026/03/10 10:00 ---
    [INFO] マスタファイルの読み込みを開始します
    [INFO] 集計処理を実行中...
    [INFO] 正常終了しました

9. コメントを書きすぎない「適正量」の判断基準

最後に、コメントポリシーで大切なのは「書きすぎない」というバランス感覚です。何でもかんでもコメントに書けばいいというわけではありません。一番良いのは「コメントがなくても読めるような、分かりやすいコードを書くこと」です。コード自体をシンプルにし、それでも分かりにくい部分をコメントで補うのが理想です。

あまりにコメントが多すぎると、肝心のコードが埋もれてしまい、かえって読みづらくなる「コメントの森」状態になってしまいます。また、コードを修正したときにコメントを直し忘れると、「書いてある説明と実際の動きが違う」という、嘘つきなプログラムになってしまい、非常に危険です。コメントもコードの一部であると考え、常に最新の状態に保つ責任を持ちましょう。

「適切な場所に、適切な理由を、簡潔に」。これが、プロのエンジニアが守っているコメントの黄金律です。パソコン初心者の方も、まずは自分の書いたコードに「自分へのメモ」を残すことから始めてみてください。それがいつか、誰かを助ける大切な道標になります。丁寧なコメントは、あなたの仕事に対する誠実さを表す鏡でもあるのです。