請求項は自然言語／人工言語？
請求項は、日本語や英語といった自然言語を使います。しかし、同じ自然言語を使う日常会話とは随分違いますね。請求項には格段の厳密さが要求されるからです。
その厳密さという点から見れば、請求項はプログラミング言語（人工言語）に近いです。
・・そう考えると、プログラミング技法の歴史と、請求項の書き方の変遷とに、奇妙な一致が見えてきます。
草創期のプログラミング技法
まずは、草創期のプログラム事情を見てみましょう。
コンピュータが実用化され、その有用性が認められるようになるにつれ、その上で動作するプログラムは次第に大規模なものとなっていった。ソフトウェアの低品質、納期遅れ、予算超過が頻発し、大規模なプログラムを正当に動作するように記述することの困難さが認識されるようになった。
引用元https://ja.wikipedia.org/wiki/構造化プログラミング
草創期のプログラムの大変さが伝わってきますね。当時、プログラムの動作主体、つまりプレーヤーは、コンピュータ１台でした。プログラムがどんなに長く複雑多岐になろうと、プログラマーはコンピュータ１台分の動作を一気呵成に書き連ねていたわけです。
一気呵成式の請求項
この草創期のプログラミング技法に近いのが、一気呵成に書き連ねるタイプの請求項です。例えば、こんな請求項になります。
【請求項１】
マイクで変換した音声信号を通信先に送信し、前記通信先から受信した音声信号をスピーカで再生する、携帯可能な電話機（携帯電話のこと）。
これは短い請求項の例です。一気呵成ゆえに、単刀直入で、発明の動作をそのまま表現しています。そのため、読んで頭に入りやすいですね。一見して、動作の主体が携帯電話一つであるというのが、ポイントです。この請求項のプレーヤーはひとり（一人称）なのです。読み手はそのプレーヤーになって請求項を読みますから、分かりやすい作文になります。
一気呵成式の問題点
しかし、分かりやすいのは、請求項が短いうちだけです。これに電話番号用の数字キーが加わり、オンフック用のキーが加わり、回線要求の発呼が加わり、物理層からアプリ層までの各種機能が加わり、条件によって動作を場合分けするとなると、一気呵成式の請求項は急に難しくなります。
どうなるかというと、（１）多数の構成要件を説明しなければならない。（２）それら多数間の関係も説明しなければならない。（３）条件の場合分けに応じて動作を分岐させる。（４）説明があっちに行ったりこっちに飛んだり切った貼ったする。・・・ことになります。いくら正しい請求項でも、読み手の頭は付いていけず、迷子になるでしょう。
請求項が長くなると、一気呵成の勢いがなくなります。まるでコードがもつれ絡まったようなカオスの状態（初期プログラム技法におけるgoto文を必要以上に濫用した状態に近い？）。一気呵成どころか青息吐息になるわけです。
上述した草創期のプログラム事情の言い方を借りるなら、【大規模な発明を正当に動作するように記述することの困難さが認識されるようになった】といったところです。
一気呵成式の現在
一昔前に比べれば、一気呵成式の請求項は少なくなりました。主流の書き方ではないです。
方法の発明でさえも、【～～し、～～し、～～する方法】という一気呵成の書き方は古く、【～～するステップと、～～するステップとを備えた方法】という書き方が主流です。
よほど短い請求項でない限り、一気呵成式の請求項は書かれないでしょう。
一気呵成式の使い途その１
一気呵成式の請求項はもう過去のものという結論でもよいのですが・・
その書き方自体は、請求項の中で部分的に活躍しています。
例えば、発明の前提を、請求項１の第一段落に前書きする場合があります。【であって書き】とか【おいて書き】とか【ジェフソンタイプ】とか【whereinの前】とか【two-part formの頭】とかいいますね。落語で言えば枕、漫才で言えばツカミになります。
つまり導入部ですね。ここが一気呵成式で読みやすくなれば、技術の専門家でない人（例えば裁判官）にも、ハードルが低く見通しの良い請求項になります。
一気呵成式の使い途その２
また例えば、発明の締め括りを、請求項１の最終段落に書く場合があります。先の例の携帯電話をもう一度見てみましょう。携帯電話として大切な要件が一つ足りないことに気付かれましたか？
【請求項１】
マイクで変換した音声信号を通信先に送信し、前記通信先から受信した音声信号をスピーカで再生する、携帯電話。
厳密に言えば、大切な動作が足りません。それは、携帯電話で通信先と会話をするということ。つまり、送信と受信を交互に行いうる機能（全二重とか半二重とかいうもの）です。もちろん、発明のポイントがそこでなく、かつ当たり前だからあえて省くという請求項のテクニックもあります。また下位請求項で会話動作それ自体が必要になったときに言及するというやり方もあります。普通はそちらの方がよいでしょう。なぜなら、途中で用もなく中途半端に全二重／半二重に言及すると、その後の動作全体を全二重／半二重に整合させなければならず、余計な限定となりうるからです。それでも書くなら、発明の締め括りとして請求項１の最終段落にサラリと書くことになります。こういう箇所も何気に一気呵成式になります。こんな感じでしょうか。
【請求項１】
・・・・・前段は同じ・・・・・・・
前記送信と前記受信とを相互または同時に行う
ことを特徴とする携帯電話。
そもそも複雑に書けずに短くまとめる形の一気呵成式だからこそ、導入部や締め括りに余計な限定も生じにくいです。一気呵成式の得手を活かした使い途です。
草創期編の小括
一気呵成式という書き方は、場所を選んで活きるというお話でした。
次回は、構造化プログラミングと請求項の書き方との奇妙な一致です。