本記事は特定企業や特許の是非を断定することを目的としたものではなく、公開情報をもとに整理したものです。
2026年9月3日、ELYZAが「業務AIアプリをAIで作成する仕組み」について特許を取得したと発表した。
Xでは「これ前からあった仕組みでは」「この範囲で特許って通るんだ」といった反応がかなり流れていて、ITmediaでも取り上げられている。
自分も最初は「AIでアプリを作る仕組みそのものを取ったの？」と思ったが、実際の特許公報を読むとそこまで単純ではなかった。
そこで、何が権利化されたのか、出願前に似た技術はなかったのか、なぜ既存技術っぽく見えても特許として成立し得るのかを整理してみる。
なお、自分は特許の専門家ではない。この記事は公開されている特許公報や各サービスの資料を技術者目線で読んだもので、侵害の有無や特許の有効・無効を法的に判断するものではない。誤りがあればコメント等で指摘いただけると助かります。
何の特許なのか
対象は特許第7759639号。
| 項目 | 内容 |
|---|---|
| 特許番号 | 特許第7759639号 |
| 発明の名称 | アプリケーション開発システム、方法及びプログラム |
| 特許権者 | 株式会社ELYZA |
| 出願日 | 2024年12月19日 |
| 特許公報発行日 | 2025年10月24日 |
ELYZAの発表では、AIによる要件整理、入力変数を含むプロンプト生成、入力フォーム・出力画面、テストデータ生成、作成後の修正などを特許化したと説明している。
実際の特許には12の請求項がある。請求項2〜10は請求項1に追加条件を加えたもので、要件の評価、出力形式、プロンプト編集・評価、テストデータ、入力項目変更時の再生成などが追加されている。請求項11・12は、請求項1とほぼ同じ中核部分を「方法」「プログラム」として記載したものだ。
この記事では、権利範囲を考えるうえで中心になる請求項1を主に見ていく。
請求項1を処理フローにすると
そのまま読むとなかなかつらいので、処理の流れに直すと大まかにはこうなる。
① アプリの説明文を取得
② 生成AIでプロンプトを生成
③ プロンプトに入力項目を変数として含める
④ 生成したプロンプトを表示
⑤ 完成したアプリでユーザーが値を入力
⑥ 値を変数に入れる
⑦ 生成AIへ送信
⑧ 出力結果を表示
例えば「問い合わせ内容から返信メールを作るアプリが欲しい」と入力すると、
以下の問い合わせに対する返信メールを作成してください。
問い合わせ内容: {inquiry}
返信のトーン: {tone}
のようなプロンプトが作られる。
完成したアプリでは利用者が {inquiry} や {tone} に相当する値を入力し、それを反映したプロンプトを生成AIに渡して結果を表示する。
明細書でも、入力事項や入力形式、出力形式などを生成AIで自動生成し、そのプロンプトに基づいてフォームを生成する実施例が説明されている。
大まかには、この一連の構成が今回の特許の中心になっている。
「AIでアプリを作る」が全部対象ではない
例えば、
「Todoアプリを作って」
↓
AIがReactのコードを生成
↓
Webアプリ完成
という仕組みは、先ほどの請求項とはかなり構造が違う。
ELYZA自身も発表で、
本特許は、特許請求の範囲に記載された具体的な構成について権利化されたものであり、生成AIによるプロンプト作成やAIアプリ開発一般を独占する趣旨のものでは一切ありません。
と説明している。
なので「LovableやClaude Codeなど、AIでアプリを作るサービスは全部この特許に引っかかる」という理解ではなさそうだ。あくまで、請求項に書かれている構成を備えているかどうかを見る必要がある。
では出願前に似たものはなかったのか
ELYZAの出願日は2024年12月19日。
それ以前のサービスを探すと、Pickaxeにかなり近い機能が見つかった。
Pickaxeは2024年5月に「Automatic AI Tool Builder」を公開している。当時の案内では、AIが作りたいツールについて質問し、その回答からプロンプトを生成する仕組みが説明されている。
さらに2024年10月の投稿では、フォームの入力値を変数としてプロンプトに埋め込む仕組みも確認できる。
例えば、
Welcome the user and respond in {preferred language}
のように、入力値を動的にプロンプトへ差し込む。
つまり出願前から、AIによるプロンプト生成、フォーム入力、変数を含むプロンプト、LLM実行という部品は存在していたように見える。
ただし、「Automatic AI Builderが変数付きプロンプトとフォームを一体として自動生成していた」と確認できる確度の高い一次情報までは見つけられなかった。
似た部品があれば特許にならない、とは限らない
ここで出てくるのが「新規性」と「進歩性」。
新規性は、すでに同じものが存在していたかどうか。
進歩性は、完全に同じものがなくても「既存技術から普通に思いつく内容ではないか」を見るものだ。
例えば、
既存技術A
AIがプロンプトを作る
既存技術B
フォーム入力をプロンプト変数に入れる
があったとして、AとBを組み合わせることが当時の技術者にとって容易だったのか、という話になる。
特許庁の審査基準では、完成した発明を知った後から「AとBを組み合わせれば簡単」と考える、いわゆる後知恵だけで進歩性を否定しないよう求めている。
なので、Pickaxeに似た機能が複数あったというだけで「この特許には進歩性がない」とまでは言えない。
エンジニア目線だと「いや、それ普通に組み合わせない？」と思ってしまうのだが、この感覚だけでは特許上の根拠にはならないらしい。この辺から一気に難しくなる。
審査でも生成AI関連の先行技術は見られていた
J-GLOBALの審査官引用文献には、特許第7564601号などが掲載されている。
これは株式会社ニューロベイスの特許で、ざっくり言えば、
作りたいプログラムの概要
↓
自然言語処理モデルが詳細仕様を生成
↓
表示・編集
↓
プログラムコードを生成
というもの。
ELYZAと似ているが、最終地点が違う。ニューロベイスはプログラムコードを生成するのに対し、ELYZAは生成したプロンプトをAIアプリの処理として利用する。
生成AIによる要件評価やテスト自動化に関する資料も引用されているので、少なくとも「生成AIだから新しい」で素通りしたわけではなさそうだ。
一方、公開されている審査官引用文献にはPickaxeは見当たらなかった。今回調べた中ではかなり気になる先行例だったので、審査時にどのように扱われていたのか気になるところではある。
出願後を見るとGoogle Opalも興味深い
この特許が後発サービスにどう関係しそうか考えていて、気になったのがGoogle Opalだった。
Googleは2025年7月24日にOpalを公開している。ELYZAの出願後なので、先行技術にはならない。
ただ、公式ドキュメントを見ると、Opalには User Input、Generate、Output というステップがある。
利用者から入力を受け取り、その入力をGenerateのプロンプトから参照して生成AIを実行し、Outputで結果を表示する。また、自然言語からワークフロー自体を生成することもできる。
| ELYZAの請求項1を簡略化 | Google Opal |
|---|---|
| 作りたいアプリの内容を入力 | 自然言語でアプリを説明 |
| アプリを構築 | Opalがワークフローを構築 |
| 入力項目を持つ | User Input |
| 入力値をプロンプトで利用 | Generateから入力を参照 |
| 生成AIを実行 | Generate |
| 結果を表示 | Output |
公開されている機能だけを並べると、似て見える部分は多い。
一方で、ELYZAの請求項には「説明文をもとに生成AIがプロンプトを生成する」「入力事項を変数として含む」といった条件もある。Opalの公開資料だけでは内部でどうプロンプトを生成しているかまでは分からない。
なので、これは「Opalが特許を侵害している」という話ではない。出願後にも似た設計思想のAIアプリBuilderが登場している、という例として興味深いという程度に留めておきたい。
特許は存在するだけでも影響する
企業が新しいサービスを出すとき、他社特許に抵触しないか事前に確認することがある。
FTO（Freedom to Operate）調査と呼ばれるもので、要するに「このまま提供して問題ないか」を確認する調査だ。
今後国内企業が、
作りたいAIツールを自然言語で説明
↓
AIがプロンプトと入力項目を生成
↓
フォーム付きAIアプリとして公開
というサービスを作る場合、ELYZAの特許が確認対象になる可能性はある。
問題なしと判断する場合もあれば、実装を変えたり、ライセンスや特許自体の有効性を検討したりすることも考えられる。
ELYZAは「AIアプリ開発一般を独占する趣旨ではない」と説明している。一方で、今回確認した発表には「防御目的のみ」「競合には権利行使しない」といった不行使方針までは書かれていなかった。
個人的には、特許が成立したことそのものよりも、今後この権利をどう使うのかのほうが気になっている。
「異議申立てする」という話も見かけたが
Xでは「特許異議を申し立てればいいのでは」という反応も見かけた。
ただ、特許異議の申立てはいつでもできるわけではない。特許庁によると、特許掲載公報の発行日から6か月以内に限られる。
この特許の公報発行日は2025年10月24日なので、通常の特許異議申立期間は2026年4月ですでに終了している。
残念ながら（？）、今から「ちょっと異議申し立ててくる」はできない。
一方で、成立した特許が今後絶対に覆らないという意味でもない。利害関係人であれば、別制度である特許無効審判で新規性や進歩性などを争う余地は残っている。
まとめ。特許は難しい
今回かなり調べたのだが、最終的な感想はこれだった。
特許難しい！！！
技術だけを見れば、どうしても「これとこれを組み合わせるのは自然では？」と考えてしまう。自分が普段設計をするときなら、既存の機能AとBがあって要件を満たせるなら、普通に組み合わせる選択肢を考えると思う。
でも、それと「特許法上、当時の技術者が容易に想到できたと証明できる」は全然別の話だった。
逆に、特許になったからといって「この会社が世界で初めてこのアイデアを考えた」と単純に理解するものでもない。
今回のPickaxeもそうで、個々の構成はかなり近い。ただ、「じゃあ出願時点で請求項全体と同じものがあったのか」「その組み合わせが容易だったと何を根拠に言えるのか」まで進むと、急に話が難しくなる。
エンジニアの「これ普通では？」という感覚と、特許制度の「普通だったと証明できますか？」には思った以上に距離がある。
生成AIは特に、数か月前には珍しかった実装があっという間に当たり前になる分野だ。WebサービスやOSS、論文、フォーラムに技術が散らばっていることもあって、どの時点で何が当たり前だったのかを後から整理するだけでもかなり大変そうだ。
最初は「こんなの特許になるんだ？」というところから調べ始めたけれど、今は「なるほど、これ簡単に白黒つけられる話じゃないな」に落ち着いている。
ただ、後発サービスへの影響はあり得るので、ELYZAがこの特許を今後どう運用するのかは引き続き気になる。
参考資料
- ELYZA Works、業務AIアプリをAIで作成する仕組みにおいて特許を取得（ELYZA）
- 特許第7759639号（J-GLOBAL）
- 特許情報プラットフォーム J-PlatPat（特許庁・INPIT）
- 新規性・進歩性の審査基準（特許庁）
- Automatic AI Builder for Faster Prompt Writing（Pickaxe Community）
- Why does a Pickaxe form and chatbot have a different prompt structure?（Pickaxe Community）
- Introducing Opal（Google Developers Blog）
- Opal Overview（Google for Developers）
- 特許異議の申立てQ&A（特許庁）
- 特許権侵害への救済手続（特許庁）