QGIS、最初のポリシーが失敗した後にAI支援のコントリビューションを禁止
QGISは、従来はラベル付けされたAI利用を認めていたものの、2026年10月7日に承認された厳格なポリシーの下でAI支援のコントリビューションを禁止した。このオープンソースの地理情報プロジェクトは現在、LLM、AIシステム、またはエージェントベースのワークフローで作成されたコードを禁じている。違反した場合、コードの差し戻しやコントリビューター権限への制裁を受ける可能性がある。
この決定は、低品質な自動生成パッチを排除するための新たな規則にとどまらない。QGISはまず、開示と人間の責任を軸とする、より寛容なアプローチを試みた。だがプロジェクト参加者は、そのアプローチではメンテナーを過剰なレビュー作業から守れず、コミュニティ開発を支える信頼も維持できないと結論付けた。
この経験により、QGISは広がりつつあるオープンソースの分断の一方に立つことになった。QEMUもAI生成のコントリビューションを拒否している一方、Linux kernelは人間が責任を負うことを条件に開示済みの支援を認めている。争点は、プロジェクトの入口で制限するか、レビュー時の説明責任に委ねるかだ。
最初のポリシーが失敗した後、QGISはAI支援のコントリビューションを禁止
決定的な変更は、開示してもAI支援コードが採用対象にはならなくなったことだ。
承認されたAI tool policyでは、メインのQGISリポジトリにおいて、LLM、AI、またはエージェント支援によるコードのコントリビューションは一切認められないとしている。また、後から判明した場合には、コードの差し戻しやコントリビューターへの制裁につながる可能性があると警告している。
QGISは、QGIS Enhancement Proposal（QEP）を通じて改定文言を採択した。QEPは、重要な技術的変更やガバナンス上の変更を議論し、記録するためのプロジェクトの手続きである。コントリビューターのNyall Dawsonは9月24日に提案を開始し、これを「NOT ALLOWED」への正式な切り替えと説明した。
この提案は10月5日に投票段階へ進んだ。10月7日には、名前が明らかにされた4人のプロジェクト参加者による賛成票を受け、承認済みと宣言された。Dawsonは同日、この変更をプロジェクトのenhancement-proposalリポジトリへマージした。
この文言は重要である。QGISは以前、より寛容なポリシーを運用していた。AIの関与は開示・ラベル付けでき、人間が関与するアプローチの下でレビューを受けられた。コントリビューターは責任を負い続け、ラベルはパッチの作成方法に関する情報をレビュアーに提供した。
ポリシー議論の参加者によれば、この妥協策は運用上失敗した。あるレビュアーは、「AI Assisted」ラベルが付けられたプルリクエストが約50件あったと見積もった。そのうち約40件はマージされずにクローズされたが、これらの数字は正式な監査ではなく、議論の中で示されたものだ。
以前のプロセスでは、コミュニティの労力を過度に消費するコントリビューションに「extractive」ラベルを付けることも想定されていた。ある参加者によると、そのラベルは一度も作成されなかった。この欠落により、メンテナーは日々のリポジトリ運用に一貫して反映されないポリシー概念を抱えることになった。
議論では4件のAI支援プルリクエストが参照され、10月2日にクローズされた。対象は分類ロジック、PostgreSQLリスナー、共有地理空間データセット、プロバイダーの並列作成に及んだ。この範囲は、対立が見た目だけの変更に限られていなかったことを示している。
このポリシーは、メインのQGISリポジトリに対するコードのコントリビューションに特に適用される。採択された文言は、QGISのすべてのチャネルにおけるAI支援のissue、コメント、翻訳、ドキュメント変更を明示的にすべて禁止するものではない。
複数のコントリビューターは、文章によるやり取りも対象とする、より広範なルールを求めた。一方で、生成コードをリサーチ、オートコンプリート、翻訳、非公開レビューと区別する、より限定的な文言を望む意見もあった。最終文面では、より広い表現である「AI or agent assisted code contributions」が維持された。
この未解決の境界は、執行の場面で重要になる。自律型コーディングエージェントが禁止対象に含まれることは明らかだ。モデル生成コードをパッチにコピーするコントリビューターも、対象となるように見える。
機械学習によるオートコンプリート、AI支援デバッグ、設計ブレインストーミングの扱いは、より明確ではない。これらの活動は、識別可能な生成テキストの塊を提供せずとも、コードに影響を与え得る。
現時点でQGISは、閉じた境界を選んだ。コントリビューターは、禁止されたコードをラベル付け、レビュー、または個人的な責任の受諾によって許容可能にすることはできない。
メンテナーの時間が希少資源になった
QGISは、レビューへの注意を、提出されるすべてのパッチに無料で付随するサービスではなく、限りあるコミュニティ資産として扱っている。
AIコーディングシステムは、経験豊富なメンテナーが評価するよりもはるかに速く、もっともらしい変更を作り出せる。レビュアーは依然として、影響を受けるサブシステムを理解し、前提をテストし、エッジケースを調べ、将来の保守を考慮しなければならない。
この非対称性は、オープンソース参加の経済性を変える。パッチの生成には数分しかかからない場合がある。一方、成熟した地理空間アプリケーションにその変更が属するべきかを判断するには、数時間から数日を要することがある。
QGISは小規模なデモ用リポジトリではない。project overviewでは、マッピングおよび地理空間分析におけるデスクトップ、サーバー、Web、モバイルでの利用が説明されている。コミュニティは2,000を超えるプラグインも保守している。
この環境への変更は、データ形式、座標系、レンダリング、空間データベース、自動化ワークフローに影響を及ぼす可能性がある。局所的には正しく見えるパッチでも、コントリビューターの当面のテストケースを超えた影響をもたらす可能性がある。
したがって、レビューは自動チェックの通過だけに依存しない。メンテナーには、コントリビューターが周辺コードを理解し、提出後の質問に答えられるという確信が必要だ。
ある参加者は、この信頼の問題について特に率直な説明を示した。そのコントリビューターは、LLMを使ってバグを調査し、変更を提案させ、コードをレビューした後、AI支援による回帰修正を2件提出していた。
そのコントリビューターは、これらのパッチが能力があるかのような錯覚を生んだと書いている。このツールによって、独力で作業を支えられるだけの知識を身につけなくても、複雑なコードベースを修正できるように思えたという。
この告白は、QGISのAIコントリビューションポリシーの根底にある中心的な懸念を捉えている。パッチは単独で届くものではない。それは、その作者、レビュアー、そして後に影響を受けたコードを保守する人の間に関係を生み出す。
知識のあるコントリビューターなら、なぜ変更が安全なのかを説明し、フィードバック後に修正し、関連する不具合を見つけられる。モデル出力を転送するだけの人には、そのいずれもできないかもしれない。
するとレビュアーが、実質的な推論の作者となる。問題を再構築し、提案された解決策を検証し、パッチがすでに理解していると主張する内容を提出者に教えなければならない。
この負荷は、プロジェクトにもたらす知識より多くの知識を繰り返し消費する場合、搾取的なものになる。リポジトリは提案された変更を得るが、コミュニティはリリース、既存コントリビューター、あるいは慎重に準備された修正に充てられたはずの時間を失う。
危険なのは、単にAI生成コードにエラーが含まれることではない。人間が作成したパッチもレビューに通らず、エッジケースを見落とし、回帰を招くことがある。
違いは提出能力にある。コーディングエージェントは、もっともらしいパッチをさらに作るコストを下げるが、そのパッチが信頼に値することを証明するコストは下げない。
QGISのコントリビューターは、この圧力をコミュニティの継続性とも結び付けた。オープンソースプロジェクトには、徐々にレビュアー、メンテナー、トレーナー、サポート提供者へと成長する新規参加者が必要だ。
AIによって人々が学習過程を飛ばせるようになれば、こうしたコントリビューターは他者の作業をレビューするために必要な知識を得られないかもしれない。プロジェクトはメンテナーを増やさずに、より多くの提出を受け取ることになる。
これは不健全な漏斗を生む。より多くの人がコードを生成できるため、最も広い入口は拡大する。だが、受け入れ判断は依然として経験豊富な人間が行うため、最も狭い出口は固定されたままだ。
適切に保守されたengineering knowledge baseは、アーキテクチャや過去の判断を再発見する時間を減らせる。しかし、不慣れなパッチに対する責任を、その作者からボランティアのレビュアーへ移すことはできない。
QGISは、漏斗に入るものを制限することで対応した。このポリシーは、出荷対象を決める責任を担う人々を守るため、潜在的に有用なAI支援の変更を犠牲にしている。
真の分断は、制限か人間の説明責任かにある
オープンソースプロジェクトは人間が責任を負い続ける点では一致しているが、責任だけでAI生成の量を制御できるかについては意見が分かれている。
QGISは現在、制限型のモデルを採用している。プロジェクトは、開示、テスト、人間のレビューによって個別のパッチが受け入れ可能になるかをメンテナーが評価する前に、AI支援コードを除外する。
QEMUも同様の境界を採用している。同プロジェクトのcode provenance policyは、ChatGPT、Claude、Copilot、Llamaなどのツールが生成したコンテンツを含む、またはそこから派生したと考えられるコントリビューションを受け付けないとしている。
QEMUは、そのルールを部分的に出所に基づいている。コントリビューターは、一般にDCOと呼ばれるDeveloper Certificate of Originを通じ、パッチを提出する権利を証明する。DCOは、コントリビューションの出所と提出権に関する人間による法的な証明である。
QEMUは、現在の生成ツールでは著作権およびライセンスの状態を確立するのが難しいと主張する。学習資料には互換性のない条件のコードが含まれる可能性があり、生成出力の法的扱いも依然として定まっていない。
ただし、そのポリシーには重要な点でより限定的な側面がある。QEMUは、生成された出力がコントリビューションに入らない限り、アプリケーションインターフェースの調査、静的解析、デバッグなどの活動にAIを使うことを認めている。
QGISは、受け入れ可能な補助活動の同等の一覧を示していない。その簡潔なポリシーは、詳細な例外よりも明確な禁止を優先している。
Linux kernelは別の道を選んだ。assistant guidelinesは、認証とレビューの義務を人間の提出者に課したうえで、AIの関与を認めている。
このプロセスでは、AIエージェントはSigned-off-byタグを追加できない。人間が生成コードをレビューし、ライセンス遵守を確認し、認証を追加し、コントリビューションの責任を引き受けなければならない。
kernelはAssisted-byタグも求めている。そのワークフローでは、再現可能なバグ、テスト済みの修正、不足している検証の明確な開示、人間が管理する提出が要求される。
このモデルは、エージェントを法的または社会的な参加者として扱うことなく、有用な自動化を維持しようとするものだ。機械は作業の作成を手助けできるが、その結果は人が所有しなければならない。
QGISも、この原則の一形態を検討した後、それを離れた。その経験は、責任を負う人が生成パッチを独力で説明または保守できない場合、人間の責任が弱くなることを示唆している。
両方の戦略は、同じ根本問題を認識している。モデル出力は自己検証されるものではなく、リポジトリはソフトウェアサービスに責任を割り当てられない。
両者の意見の違いは、プロジェクトがどこで不確実性を引き受けるかにある。Linuxはパッチを通常のプロセスに入れ、より強い人間の説明責任を求める。QGISは、パッチがレビュアーの注意を要求できるようになる前に、そのカテゴリーを遮断する。
制限的なアプローチは、メンテナーに単純な拒否根拠を与える。パッチのどの程度がモデル由来なのか、人間による編集が十分に変容させたのかを議論する必要がない。
ただし、執行はなお主としてコントリビューターの誠実さに依存する。生成コードには信頼できる識別子がなく、自動AI検出器も、制裁に必要な確信をもって作者性を立証することはできない。
説明責任を重視するアプローチは、検証不能な純粋性テストを避ける。開発中に使われたすべてのツールを再構成しようとするのではなく、テスト、来歴、説明、責任の所在を評価する。
しかし、そのプロセスも大量の変更を前にすれば機能しないことがある。よく書かれた開示が複雑なレビューを短縮するわけではなく、人間による署名が欠けている専門知識を生み出すわけでもない。
したがって、この二つのモデルは異なるリスクを最適化している。Linuxは人間の責任を維持しつつ、AI支援による開発へのアクセスを守る。QGISは、広範な開発手法を排除することで、限られたレビュー能力を守る。
どちらの方針も、オープンソース全般における問題を決着させるものではない。各プロジェクトは、自らのガバナンス、メンテナーの供給、人法的リスクへの許容度、貢献者文化に境界線を合わせる必要がある。
明確な禁止でも、境界は曖昧なまま残る
QGISのルールは中核では単純だが、現代の開発ツールが支援と著作者性を融合させる周縁部では不確実性が残る。
コーディングエージェントに機能実装を依頼し、その結果を提出する行為が禁止されていることを誤解する貢献者はほとんどいないだろう。難しいケースは、AIが人間が独自に書いたコードへ至る過程を変える場合に始まる。
提案をめぐる議論では、貢献者たちが補完、コードレビュー、翻訳、調査、デバッグに関する例を挙げた。現代の開発環境は、ユーザーがチャットボットを一度も開かなくても機械学習を利用できる。
エディタがモデルを使って補完候補を順位付けすることもある。検索エンジンが通常の検索結果より前にAI生成の回答を表示することもある。翻訳サービスが、貢献者による英語の識別子やコメントの作成を支援することもある。
開発者がLLMに不慣れなサブシステムの説明を求め、その後チャットを閉じて手作業でパッチを書くこともある。別の開発者はモデルを非公開のレビュアーとして使い、複数の誤った提案を捨てながら一つの警告だけを受け入れるかもしれない。
こうしたケースは、生成コードか人間が著したコードかという分類にはきれいに収まらない。人とシステムの間で、開発の異なる段階において情報と判断が行き来するからだ。
ある参加者は、禁止対象をLLMやAIエージェントが「書いた」コードに限定する案を出した。この文言なら、生成された実装を認めずに、ブレインストーミング、検索、分析の余地を残せる。
プロジェクトのリーダーたちは、承認前にルールを狭めることを見送った。Dawsonはこの禁止を、個別の用途について適切な議論が行われた後、将来の提案で選択的に再開できる閉ざされた扉として位置付けた。
別の貢献者は、この方針を暫定措置と呼んだ。プロジェクトリーダーもまた、この制限は必ずしも恒久的でも普遍的でもないと述べた。
この流れは意図的なトレードオフを示している。QGISは、現時点のデフォルトに関する曖昧さを取り除くため、周縁的なケースをめぐる曖昧さを受け入れた。
このアプローチは即時の負担軽減をもたらす一方、適正手続きに関する疑問を生む。この方針では、禁止された支援が後から判明した場合、貢献者の権利に関する制裁を可能にしている。しかし、調査手順、証拠基準、異議申し立ての道筋は定義していない。
また、どの程度のAIの影響がコードを「支援された」ものにするのかも明示していない。関数をそのままコピーするのは分かりやすい。開発者の考え方を変えるアーキテクチャの説明は、より難しい。
プロジェクトリーダーたちは、貢献者のコンピュータを調べることはできないと認めた。あるリーダーは、貢献者自身の思考がコードを書いたかどうかを中心に据える善意のテストを提案した。
この基準は、技術的な検出よりもコミュニティの信頼を反映している。隠蔽が容易であっても、貢献者が方針を尊重することを求めるものだ。
信頼に基づく執行はオープンソースでは一般的である。メンテナーはすでに、来歴、テストの限界、利益相反、第三者コードについて貢献者が正しく申告することに依存している。
方針に制裁が含まれる場合、その重要性はさらに高まる。誤った告発は、特にコーディングスタイルが一般的に見えたり、異常に洗練されて見えたりする場合、正当な貢献者を萎縮させかねない。
包括的な制限は、有用なアクセシビリティ支援も排除しうる。翻訳、コード説明、個別最適化された支援は、異なる言語や認知上の障壁を越えて活動する貢献者を助けられる。
こうしたコストは方針を無効にするものではない。むしろ、この制限をAI支援開発に関する完成された理論ではなく、モラトリアムとして理解すべき理由を示している。
QGISの主張で最も強い部分は運用面にある。最初の方針では負担を十分に減らせなかったため、プロジェクトはメンテナーが迅速に適用できるルールを選んだ。
最も弱い主張は、AIの影響を受けたすべてのコードが本質的に欠陥を持つとするものだろう。プロジェクト自身の議論も、その結論を裏付けてはいない。
一部の参加者は、実際に役立つ非公開レビューやコード探索について述べている。支持者でさえ、この禁止が有害な用途とともに有益な用途も捨て去る可能性を認めた。
QGISは、ケースごとの最適化よりも予測可能なガバナンスを選んでいる。これは圧力下では擁護できる選択だが、その正当性は一貫して均衡の取れた執行にかかっている。
禁止は人間の貢献者パイプラインを守る
この方針は、単にテストを通過するコードをふるいにかけることではなく、メンテナーを生み出すコミュニティを守ることに最終的な目的がある。
QGISは、リポジトリの範囲を大きく超える業務で地理空間ソフトウェアを利用する組織にサービスを提供している。ユーザーは地図を作成し、空間データを分析し、サービスを公開し、多数の形式やデータベースを接続する。
組織は、開発、トレーニング、サポートのためにQGISコミュニティから人材を採用することもできる。この関係により、ユーザーは専門知識にアクセスできる一方、経験豊富な貢献者は長期的な参加を維持しやすくなる。
AI支援によるオープンソース開発は、コード生産と専門知識を切り離す場合、この循環を乱しうる。生成されたパッチは、直近の問題を解決しても、その後にサブシステムを理解する人を生み出さない可能性がある。
その損失は後の回帰で明らかになる。メンテナーには、当初の制約を覚え、新たな症状を調査でき、改訂版が意図した動作を維持しているか判断できる人が必要だ。
モデルとのセッションには継続的な社会的責任がない。その出力を提出する人間も、目先のパッチが受け入れられれば姿を消すかもしれない。
オープンソースには、以前から単発の貢献が時折あった。懸念されているのは規模である。コーディングエージェントは、ときおり見られるパターンを、大規模な変更が絶えず流れ込む状態へと変えうる。
この流れは、技術的レビューとコミュニティとしての判断の両方に負担をかける。メンテナーは、新参者が学ぼうとしているのか、それとも生成された作業の検証をプロジェクトに求めているだけなのかを判断しなければならない。
この違いは、どれだけ教えることに意味があるかを左右する。レビューは品質管理の一部だが、プロジェクトが将来の協力者を育てる手段でもある。
意欲的な貢献者がサブシステムを理解する手助けに費やす時間は、投資になりうる。提出物について議論できない人の変更を修復する時間は、そうした見返りをほとんど生まない。
だからこそ、QGISの決定を自動化への恐怖に還元することはできない。このプロジェクトが守ろうとしているのは、貢献者が努力と深まりつつある理解を持ち寄り、メンテナーがレビューと指導を提供するという特定の交換関係だ。
AIコーディングは、その見かけ上の均衡を変える。通常ならその作業と結び付く知識を築く前に、より完成度の高そうな成果物を提示できるようになるからだ。
パッチはコンパイルでき、目に見える症状に対処しているかもしれない。それでも、経験豊富なレビュアーだけが気付く、作り物の前提、不完全なテスト、偶発的な挙動に依存している可能性がある。
地理空間ソフトウェアでは、隠れた前提が特に大きなコストにつながりうる。座標参照系、ジオメトリの妥当性、プロバイダーの挙動、データベースのセマンティクスは、小さな変更を幅広い互換性の問題に変えることがある。
自動テストは役立つが、テストが符号化するのは既知の期待値だ。生成された修正が、あらゆるワークフロー、プラットフォーム、データソース、性能上の制約を尊重していることまでは保証しない。
この禁止は、貢献者に提出前にその知識の隔たりを越えることを求める。依然としてコードを学び、ドキュメントを参照し、設計を議論し、人間が著した変更を準備することはできる。
この要件は参入障壁を上げる。AIを慎重に利用し、提出するすべての行を理解している有能な開発者にとっても、フラストレーションとなりうる。
QGISは、メンテナーがすでに別の選択肢を経験してきたため、この排除を受け入れている。このプロジェクトは、候補パッチの数を最大化することより、レビュアーの持続可能性を優先している。
この立場は、社内でコーディングエージェントを導入する組織にもシグナルを送る。公開リポジトリは、非公開で生成された作業を無制限に下流で検証するサービスではない。
企業は自社のデプロイメント向けにQGISの変更を生成し、自らの環境内でテストできる。共有プロジェクトへの提出は、ボランティアとコミュニティ資金で支えられるメンテナーに新たな義務を移すことになる。
アップストリームでの受け入れを望む組織は、責任を持つ人間の専門知識を提供する必要がある。より深い社内レビュー、既存の貢献者への資金提供、あるいはQGISアーキテクチャを理解する従業員の育成を意味するかもしれない。
その結果、オープンソースソフトウェアを利用することと、その生産に参加することの境界はより明確になる。AIは後者を試みるコストを下げるが、QGISは必要な理解水準までは下げないと主張している。
方針が機能しているかを示す三つのシグナル
次の試験は、AI支援のプルリクエストが消えるかどうかではなく、QGISが正当な参加を弱めずにレビュー能力を得られるかどうかだ。
最初のシグナルは、今後数か月間のプロジェクトのプルリクエストバックログである。メンテナーが禁止を採用した理由の一部は、生成された提出物が人間によるレビューの速度を上回って届く可能性があったからだ。
キューの縮小、意思決定の迅速化、あるいは大規模に広がりすぎたパッチの減少は、方針の運用上の主張を支持するだろう。過負荷が続くなら、AI支援による貢献はレビュー圧力の一因にすぎなかったことが示される。
この指標には文脈が必要だ。QGISの開発量は、リリーススケジュール、貢献者の稼働状況、大規模な機能開発によって変動しうる。
そのためメンテナーは類似した期間を比較し、却下された提出物と受け入れられた作業を区別すべきだ。プルリクエストの生の件数だけでは、レビュー品質が改善したかは分からない。
二つ目のシグナルは、許容される用途を定義する後続のQEPである。プロジェクトリーダーたちは、この制限を将来の提案が選択的に緩和できる出発点として繰り返し説明してきた。
非公開レビュー、翻訳、調査、補完に対する限定的な例外は、QGISが有害な提出パターンと低リスクの支援を区別できることを示すだろう。また、実務上「支援された」が何を意味するかも明確になる。
後続の提案がなければ、一時的な境界が恒久的なデフォルトになりつつあることを示す。その結果でも作業負荷は減るかもしれないが、周縁的なケースは主に非公式な判断に委ねられたままとなる。
三つ目のシグナルは、貢献者の定着だ。QGISは、経験豊富なメンテナーが活動を続けているか、新たな人間の貢献者がより深い責任へ進んでいるかを見守るべきだ。
この方針は、既存のレビュアーを守りながら、新参者が学ぶ道を維持できれば成功と見なされるだろう。メンテナー能力に対応する改善がないまま参加者が減るなら、その評価は弱まる。
執行事例も、このシグナルの中で重要な詳細を提供する。認められた違反への透明な対応は、コーディングスタイルへの疑いに基づく制裁とは異なる。
一貫性が、貢献者がこのルールを明確なコミュニティの境界と見るか、予測不能な著作者性テストと見るかを決める。公開の説明は、個人情報を露出させずに先例を定義する助けとなる。
LinuxとQEMUとの比較も有用であり続ける。Linuxは、開示、再現可能性、人間による認証がAI関連コストを抑えられるかを検証している。QEMUは、来歴に基づくより精密に範囲を定めた禁止を検証している。
寛容なプロジェクトがレビュアーを疲弊させずに品質を維持できるなら、QGISに扉を再び開くよう求める圧力は高まるだろう。検証不能なパッチの洪水が繰り返し起きるなら、QGISの早期の制限はより説得力を持つようになる。
開発者は、この方針をAIコーディング全般に対する普遍的な判断として受け取るべきではありません。むしろ、失敗に終わったガバナンスの試みへの、リポジトリ固有の回答として捉えるべきです。
今後、開発者はコントリビューションを行う前に、自身のワークフローがこのルールを誠実に満たせるかを判断する必要があります。満たせない場合、開示を行っても提出は受け入れられません。
QGISを基盤に構築する組織も、提案するアップストリーム変更を誰が支援できるのかを検討すべきです。永続的な人間によるオーナーシップを伴わない生成済み実装には、現在、却下される直接的なリスクがあります。
QGISがAI支援によるコントリビューションを禁止したのは、コード生成へのアクセスが、責任あるレビューへのアクセスを大きく上回っているとプロジェクトが結論付けたためです。今後数か月で、この隔たりを閉じることがコミュニティを守るのか、それとも曖昧さを別の場所へ移すだけなのかが明らかになるでしょう。
バックログ、次の方針提案、そしてコントリビューターのパイプラインに注目してください。これらのシグナルを合わせて見ることで、QGISが持続可能な境界を見いだしたのか、それともより困難な議論に向けた時間を稼いだだけなのかが分かるはずです。
