規程は業務フローである。
そして権限規定であり、
AI時代の業務設計の憲法になる。

日本では、AIを発明者と記載した出願は認められない。東京地判 令和6年5月16日（令和5年(行ウ)第5001号／DABUS事件）は、特許法上の「発明者」は自然人に限られると判示し、知財高判 令和7年1月30日（令和6年(行コ)第10006号）も結論を維持した。米国USPTOも2024年2月のガイダンスで、AI支援発明は自然人がsignificant contribution をしていれば特許適格としつつ、発明者は自然人でなければならないとしている。なお、このガイダンスは2025年11月28日に全部撤回され、現行版はAIを道具とし、従来の着想（conception）の基準で判断している。

つまり実務上の問題は「AIが発明者になれるか」ではなく、AIを使って生まれた発明について、どの自然人が発明者なのかを、後から説明できる形で残せるかに移った。届出フォームに次のフィールドが要る — 使用したAIツール名／AIに与えた入力（課題設定・制約条件）／AI出力のうち採用した部分／人が加えた着想・選択・検証。これは条文というより届出書の様式の問題であり、規程本体には「AIを利用した場合は利用状況を申告しなければならない」の一文があれば足りる。

→ USPTO AI発明者性ガイダンス（図解解説） ／ → 続編：着想か、実装か（日本の判例と規程から）

秘匿を選んだ発明、および出願前の発明の内容を、学習に利用されうる外部サービスへ入力する行為は、秘密管理性を崩し、場合によっては新規性喪失のリスクにも触れる。従来の秘密保持条項は「第三者への開示」を禁じているが、AIサービスへの入力が「開示」に当たるかは条文上明らかでないことが多い。

書くべきは禁止だけではない。許可リストと、その更新権限を誰が持つかを書く。禁止だけの条文は必ず破られる — 業務が回らなくなるからだ。「この用途にはこのサービスを使ってよい」を維持する責任者を置いたほうが、実効性が高い。

ひな型型の規程は「発明等」に特許・実用新案・意匠を含めるのが通例で、著作物やノウハウの扱いは会社ごとに揺れる。AI前提の開発組織では、価値の相当部分が学習データセット・評価セット・プロンプト資産・ファインチューニング済み重みに乗る。これらは特許にも著作権にもきれいに収まらない。

選択肢は2つ。規程の「発明等」の定義を広げて全部を捕捉するか、職務発明規程は特許法35条の射程に限定し、それ以外は就業規則と職務著作の規定（著作権法15条）と営業秘密管理規程で受けるか。おすすめは後者 — 35条の枠に無理に押し込むと、相当の利益の議論まで巻き込まれて設計が破綻しやすい。ただしどちらで受けるかを明記し、受け皿の文書名を規程内に書くこと。空白のまま両方の規程が「うちの管轄ではない」と言う状態が最悪である。

出願時払い・登録時払いの2点で組む設計は、会社が「出願しない」と判断した瞬間に発明者の取り分がゼロになる。会社にとって最も価値が高い発明（＝あえて出願せずノウハウとして囲う発明）で報奨がゼロになる、という逆転が起きうる。

対処は3通り。(a) 届出時に少額の一律報奨を置く、(b) 秘匿決定を独立の支払トリガとして award_event に加える、(c) 秘匿発明を実績報奨の対象に含める。(a)が最も簡単で、届出件数への効きが最も大きい。§4のシミュレータで秘匿時報奨を「出す」に切り替えると、届出したのに無報酬になる割合がどう動くか見られる。

なお、素材のひな型は第11条で秘匿報償金を置き、この点にすでに手当てをしている（登録要件を備え、秘匿して実施することで独占的な利益を生じたと会社が認定したとき5万円）。(b)の型である。会社の認定を条件にしているので、自社で使うときは、認定の手順と、出願も秘匿もしない判断（公知化・放棄）をどう扱うかを決めておくとよい。

特許法35条は「従業者等」と使用者の関係を規律するもので、業務委託先の個人事業主や他社の研究者には及ばない。スタートアップは初期にこの層の比率が高く、規程を整えたのに肝心の人が対象外という事故が起きやすい。

規程側は「対象外である」と明記するだけでよい。実質は業務委託契約・NDA・共同研究契約の知財条項で受ける。ただし規程に受け皿となる契約類型と、その締結を確認する責任者を書いておくと、抜けが構造的に減る。

35条1項の職務発明は、(i) 使用者の業務範囲に属し、(ii) 発明をするに至った行為が従業者の現在または過去の職務に属する、の2要件を満たすものをいう。副業・個人開発・OSS活動が日常化すると、この線引きの争いが増える。

規程で全ての境界を書き切ることはできない。書けるのは手続のほうである — 疑わしい場合は届け出させ、該当性は委員会が認定し、非該当なら自由発明として速やかに返す。境界を条文で定義しようとするより、境界を判定する手続を定義するほうが、はるかに機能する。これは規程設計の一般則でもある。

仕組みは要らない。3枚の紙は要る。状態遷移図・権限行列・期限表は、Excelでも手書きでもよく、システムを作る必要は一切ない。むしろ10人の会社ほど、Dが代表取締役に集中していて、意見聴取が省略されがちで、届出が口頭で済まされている。事故の確率は規模に反比例することが多い。

そして資金調達やM&Aのデューデリジェンスで最初に聞かれるのが「主要な特許の権利帰属は確実か」である。届出と承継の証跡がないと、ここで止まる。

額と件数の関係は、実務上あまり素直ではない。§4のシミュレータで確かめられるとおり、効くのは金額よりも「出しても無駄にならない」という予測可能性のほうだ。届出の3割が不出願で無報酬になる制度と、少額でも必ず何かが返る制度とでは、後者のほうが届出が続く。

ただしこれは設計上の一般論であり、特定の企業で検証された数値ではない。経験則

現行法では、その問いは成立しない。日本の裁判所（東京地判 令和6年5月16日、知財高判 令和7年1月30日）は発明者を自然人に限ると判示しており、AI単独発明として出願する経路がない。したがって実務上の問いは「AIを道具として使ったとき、どの自然人が発明者か」になる。判断材料は、課題設定・制約条件の設計・出力の選択・検証といった、人が加えた寄与の中身である。

だから規程がやるべきことは、AIの権利を定めることではなく、その寄与を後から再現できる形で記録させることに尽きる。§7①。

草案を書かせるのは有効だし、この教材の§2〜§5のような形式化はAIが得意な作業である。ただし草案が規程になるのは、協議を経て開示されたときだけだ（35条5項）。生成された瞬間に効力を持つ文書ではない。

これは形式的な手続論ではなく、実質を伴っている。協議の過程で「うちだと出願判断が2週間止まる」「委員会は実際には開かれていない」といった、条文からは絶対に読み取れない情報が出る。その情報がないまま書かれた規程は、精巧だが現場と接続していない文書になる。

よい出発点である。ひな型の価値は、法的に落としてはいけない項目を押さえたうえで、少ない手間で導入できる点にある。作成側も、職務発明規程は本来会社ごとに作るもので、ひな型をもとに微調整して使うことを想定している。気をつけたいのは、その微調整を後回しにしたまま運用を続けることだ。一般に、規程に書かれた機関（たとえば「発明審査委員会」）が自社に実在しないまま運用されている例があり、その機関が決定権者になっている遷移は根拠を失う。素材のひな型は決める人を「会社」とまとめているので、この問題は起きにくい。代わりに、社内の誰が「会社」として決めるかを決めておく。

§3の権限行列を自社の実際の役職で埋める作業は、そのための近道になる。ひな型をもとにする場合こそ、やる価値がある。