Aki Hamano

WordPressにコードで貢献するときに、AIとどのように関わるか

,

これは WordPress に限ったことではありませんが、AI の発展に伴い、開発速度が速くなると同時に、新規貢献者がコードでの貢献に以前よりも関わりやすくなっていると感じます。

その一方、貢献に AI を活用する上で、個人的に気を付けたいこと、守りたいことを挙げてみたいと思います。

コードを書くことは目的ではなく手段である

プルリクエストを提出し、それがレビューされ、マージされる。そうすると、それは計測可能な props (賛辞) として扱われ、次の WordPress リリースでのクレジットに名前が載ります。また初めての貢献であれば、自身の wordpress.org プロフィールページに「Core Contributor」というバッジも追加されるでしょう。自身の貢献が目に見える形で残るということは、貢献を続ける上での大きなモチベーションの一つだと思います。

しかし、そのような「証」を手に入れる事、つまり、コードを書いて、PR を提出して、それがマージされること自体が目的になっていないでしょうか ?

AI に対して「この Issue を解決する PR を提出して」または「この Issue で提案されている機能を実装して」とさえ伝えさえすれば、AI はすぐにそれをコードで実装し、PR の説明文を自動生成します。ですがその前に、以下のことを考えるべきだと思います。

  • その Issue がバグ報告であった場合:
    • そのバグは、現実世界や人間の操作で本当に起こりえますか ? 現実的には起こりえないものだったり、手動での再現が不可能な場合は、「won’t fix」としてクローズできるかもしれません。
    • そのバグは、本当に WordPress 側で解決する問題ですか ? プラグイン側が対処すべきものではありませんか ?
    • 本当にそのエラーを修正してもいいのですか ? 本来起こすべきエラーを暗黙的に握りつぶすことになりませんか ?
    • そのエラーを修正するだけでいいですか ? 根本的に修正すべきより大きなバグが上流に潜んでいませんか ?
  • その Issue が機能リクエストに関するものであった場合:
    • その機能は、既存機能の組み合わせで実現できませんか ?
    • その機能は、今後永遠に維持していく価値がありますか ? WordPress は非常に後方互換を大事にする OSS であるため、一度追加された API を削除することは困難です。
    • ユーザーの80%以上がその機能を使いたいと思いますか ? その機能は本当にコアに追加するべきですか？
    • 本当にその機能を追加する準備が出来ていますか ? 貢献者達の間で、その機能を追加することに関して議論は十分に行われましたか ?
    • そして何より、あなた自身がその機能に価値があると感じていますか ? その価値を自分の言葉で説明できますか ?

PR を提出してはいけない、と言っているわけではありません。AI によってコードを書くことが簡単になったからこそ、PR を提出する前に疑問を持つ事や仮説を立てる事がより重要になっていると思います。

結果として、PR を提出する必要そのものがなくなり、Issue はクローズされる可能性もあります。残念ながら、それはデータとしての props としてはカウントされないかもしれませんが、何も考えずに提出した PR よりも価値のある貢献だと自分は思います。

目的は、WordPress がよりよくなるためにどうすべきかを考え、他の貢献者と議論することだと思います。コーを書いたり PR を提出することは、それを達成するための単なる手段であり、目的ではありません。

ヒューマンリーダブルなコメントを心がける

何らかのバグを報告するために AI にそのコンテンツ生成を依頼した場合、以下のようにとても細かいコンテンツを生成する場合があります。

症状

〇〇〇〇〇〇〇〇〇〇〇〇〇 の状態で 〇〇〇〇〇〇〇〇〇〇〇〇〇 を実行すると、〇〇〇〇〇〇〇〇〇〇〇〇〇 が発生します。この事象は 〇〇〇 のときにのみ再現し、〇〇〇 のときには再現しません。また、〇〇〇 も 〇〇〇 も一切ともなわずに発生するため、〇〇〇 はこの不具合が起きていること自体に気づくことができず、〇〇〇 もまた 〇〇〇 とは異なる 〇〇〇 を見せられていることに気づくことができません。すなわち、〇〇〇 側と 〇〇〇 側の双方に対して完全にサイレントな形で 〇〇〇 が発生する、という症状になります。

期待される結果

〇〇〇 は、〇〇〇 がどのような値に設定されているかにかかわらず、少なくとも 〇〇〇 において必ず 〇〇〇 となり、〇〇〇 が意図したとおりに 〇〇〇 されることが期待されます。あるいは、それが技術的に困難であるならば、〇〇〇 に依存した 〇〇〇 によってのみ妥当と判定されるような 〇〇〇 が渡された時点で、〇〇〇 がすでに 〇〇〇 に対して 〇〇〇 を発火させているのと同様の一貫した挙動として、〇〇〇 に対して警告が通知されることが期待されます。いずれにせよ、現状のように何の通知もないまま黙って壊れる、という結果になることは期待されていません。

原因

原因は、〇〇〇.js ファイルの 〇〇 行目から 〇〇 行目に定義されている 〇〇〇 と、同ファイル内でそれを呼び出している 〇〇〇、および 〇〇〇.js ファイルの 〇〇 行目から 〇〇 行目で 〇〇〇 を組み立てている 〇〇〇 の三者のあいだの前提の不一致にあります。

具体的には、〇〇〇 は 〇〇 行目の 〇〇〇 という一行によって、〇〇〇 を 〇〇〇 という固定値を基準として 〇〇〇 へと換算しています。そしてこの換算結果は、あくまで内部的な 〇〇〇 のためだけに使用されます。ところが、実際に出力される 〇〇〇 のほうは、この換算を経由せず、〇〇〇 が記述した元の 〇〇〇 をそのまま保持したまま生成されます。この点は 〇〇 行目から 〇〇 行目にかけてのコメントにおいて、実装上の意図として明示的に記述されています。

ここで問題となるのは、〇〇〇 の中に書かれた 〇〇〇 が、〇〇〇 では 〇〇〇 ではなく 〇〇〇 に対して解決される、という 〇〇〇 仕様上の挙動です。つまり、〇〇〇 側が 〇〇〇 という固定値を前提として「〇〇〇 は 〇〇〇 より小さい」と判定したとしても、その判定は 〇〇〇 側では再現されません。〇〇〇 が 〇〇〇 より大きく設定されていると 〇〇〇 側の実効値だけが増大し、〇〇〇 側は変化しないため、両者の大小関係が逆転します。大小関係が逆転すると、〇〇〇 という形で組み立てられた 〇〇〇 の下限が上限を上回り、その結果として 〇〇〇 は論理的に 〇〇〇 となり、いかなる 〇〇〇 にもマッチしなくなります。マッチしなくなると、その内側に出力されている 〇〇〇 および 〇〇〇 は一切適用されず、〇〇〇 は 〇〇〇 すべきでない場面で 〇〇〇 され、あるいは適用されるべき 〇〇〇 が適用されないままとなります。

なお、〇〇〇 が同一の 〇〇〇 で記述されている場合においては、〇〇〇 が変化しても両者が同じ比率で変化するため大小関係は保たれ、この問題は発生しません。また、〇〇〇 を指定してもこの問題を回避することはできません。なぜなら、〇〇〇 内の 〇〇〇 は 〇〇〇 ではなく 〇〇〇 に対して解決されるためです。

修正案

〇〇〇.js ファイルの 〇〇 行目の 〇〇〇 と、〇〇〇 側の処理を整合させるように修正することで、〇〇〇 に用いられる値と実際に出力される値とが一致するようになり、〇〇〇 が通った組み合わせは必ず 〇〇〇 上でも有効な 〇〇〇 となります。すなわち、〇〇〇 を 〇〇〇 へ換算した結果をそのまま 〇〇〇 の出力にも用いる、という一貫した方針を採用します。この方針は、すでに 〇〇〇 の側で 〇〇〇 という基準が採用されている以上、システム全体として新たな前提を導入するものではなく、既存の前提を出力側にも適用するだけであるため、〇〇〇 が損なわれる心配はありません。

ただし、この方針は 〇〇〇 を実質的に 〇〇〇 へと落とし込むことを意味するため、〇〇〇 を意図的に選択している 〇〇〇 の意図を変えてしまう可能性があります。そこで、代替案として、〇〇〇 の中では 〇〇〇 が同一であることを必須とし、〇〇〇 が混在している場合にはそれを不正な値として扱う、という方針も考えられます。さらに三つ目の代替案として、〇〇〇 を受理すること自体は従来どおり継続しつつ、その 〇〇〇 が 〇〇〇 という前提に依存している場合にかぎり 〇〇〇 を発火させ、あわせて 〇〇〇 のドキュメントに 〇〇〇 に関する制約を明記する、という方針も考えられます。三つ目の方針は既存の 〇〇〇 を一切変更しないため、後方互換性の観点からは最も安全です。

テスト手順

  1. 〇〇〇 以降がインストールされた検証環境を用意し、〇〇〇 を有効化します。
  2. 〇〇〇 を編集し、〇〇〇 の直下に以下のように 〇〇〇 が混在した設定を追加して保存します。 〇〇〇〇〇〇〇〇〇〇〇〇〇
  3. 〇〇〇 が利用できる環境において以下のコマンドを実行し、生成される 〇〇〇 の内容を確認します。 〇〇〇〇〇〇〇〇〇〇〇〇〇
  4. 出力結果のうち 〇〇〇 に対応する値が 〇〇〇 となっていること、すなわち 〇〇〇 側の 〇〇〇 が換算されずに元のまま保持されていることを確認します。
  5. 〇〇〇 を作成し、〇〇〇 をひとつ配置したうえで、それに対して 〇〇〇 を設定して公開します。
  6. 〇〇〇 の設定画面から 〇〇〇 を開き、〇〇〇 を 〇〇〇 に変更します。
  7. 〇〇〇 を 〇〇〇 から 〇〇〇 のあいだの任意の値に調整したうえで、手順 5 で公開した 〇〇〇 を表示します。
  8. 〇〇〇 が 〇〇〇 であるため 〇〇〇 は 〇〇〇 として解決され、生成された 〇〇〇 は下限が上限を上回った 〇〇〇 となり、手順 5 で設定した 〇〇〇 が適用されないこと、すなわち 〇〇〇 すべきでない 〇〇〇 が 〇〇〇 されたままとなることを確認します。
  9. 対照実験として、手順 2 の値を 〇〇〇 から 〇〇〇 へ変更し、〇〇〇 を同一に揃えたうえで手順 6 から手順 8 を再度実行し、この場合には 〇〇〇 が正しく適用されること、および 〇〇〇 を 〇〇〇・〇〇〇・〇〇〇 と切り替えても挙動が変化しないことを確認します。
  10. 修正の適用後、手順 2 の設定に戻したうえで手順 6 から手順 8 を再度実行し、採用した修正方針に応じて、〇〇〇 が 〇〇〇 にならず 〇〇〇 が適用されるようになること、あるいは 〇〇〇 を有効にした状態で該当する警告が 〇〇〇 へ出力されるようになることを確認します。

これを自分が目にしたときに最初に思うことは、「So what? (要するにどういうこと ?)」です。

内容には矛盾は一つもなく、技術的にも全て正しいかもしれませんが、この Issue に取り組んだり、ここで議論するのは人間です。将来的には全て AI が対処するかもしれませんが、少なくとも現在 WordPress 開発や貢献においてはそうではありません。

もしかすると貢献者の中には、よかれと思って AI の調査結果をそのままコンテンツにペーストしている人もいるかもしれませんが、AI を使ってコンテンツを生成したかどうかが問題なのではなく、次のことを守るべきだと考えます。

  • 生成されたコンテンツを全て自分自身でレビューし、校正しましたか ?
  • 要約したり、冗長な部分を削除したりして、そのコンテンツを読む人間の負荷を軽減する努力をしましたか ?
  • そのテスト手順は、本当に自分自身で実行しましたか ?
  • AI が生成する修正案は本当に妥当なものですか ? そもそも修正案は議論して決定すべきではありませんか ?
  • そもそも自分自身が、そのコンテンツを読みやすいと感じていますか ?

コードレビュー

最近、提出された PR に、以下のようなコメントが追加されているのをいくつか見かけました。

本レビューは 〇〇〇 を実行して確認したものではなく、〇〇〇 を読んだうえでの静的な解析にもとづくものです。

変更内容の理解として、本 PR で行われている変更は以下の 〇 点であると理解しています。

  • 〇〇〇.js の 〇〇 行目付近で、従来 〇〇〇 のみを対象としていた処理を 〇〇〇 も対象とするように変更している点
  • 同ファイル 〇〇 行目から 〇〇 行目に、新たに 〇〇〇 を追加している点
  • 〇〇〇.spec.js に 〇〇〇 を検証するテストを 〇 件追加している点

良い点として、以下が挙げられます。

  • 〇〇〇 の実装方針が適切です。素朴に実装すると 〇〇〇 を使ってしまいがちですが、それでは 〇〇〇 しか取得できません。本 PR では 〇〇〇 を経由することで確実に 〇〇〇 の方向へ処理が進むようになっています。
  • 〇〇〇 の一致が担保されています。〇〇〇.php の 〇〇 行目と 〇〇〇.php の 〇〇 行目はいずれも同一の値から 〇〇〇 を導出しているため、比較対象として正しいことを確認しました。
  • 〇〇〇 が呼ばれているため、〇〇〇 が発生しません。

指摘事項（Blocking）です。〇〇〇.js の 〇〇 行目は、〇〇〇 が 〇〇〇 を含む場合に 〇〇〇 を送出します。本 PR によってこの処理が 〇〇〇 からも呼ばれるようになったため、〇〇〇 の最中に例外が送出され、〇〇〇 全体が 〇〇〇 になる可能性があります。try / catch で囲み、失敗時に 〇〇〇 へフォールバックする対応を提案します。

なお 〇〇〇 にも同一の記述があるため、本 PR で混入した問題ではありませんが、新たに到達可能となる以上は本 PR の範囲で対応することが望ましいと考えます。

指摘事項（Non-blocking）です。追加された 〇 件のテストは新規経路のみを検証しています。一方 〇〇〇 >= 0 の分岐は既存の挙動でありながら本 PR で変更を受けており、検証されていません。元の Issue でも 〇〇〇 のケースが言及されているため、あわせて assert することが望ましいと考えます。

指摘事項（Nit・任意）として、以下の 3 点があります。

  • 〇〇〇.js の 〇〇 行目の 〇〇〇 は 〇〇 行目と重複しています。一箇所にまとめる余地がありますが、現状のままでも問題はありません。
  • 〇〇〇?.〇〇〇?.〇〇〇 のオプショナルチェーンは、このコンテキストでは機能していません。
  • 〇〇〇 のあと 〇〇〇 が移動しません。〇〇〇 でも同様であるため follow-up が適切かもしれませんが、意図的な判断かどうかは明確にしておく価値があると思います。

まとめますと、方向性は妥当であり、特に 〇〇〇 の実装は評価できます。Blocking の 1 点はマージ前の対応が必要と考えます。Non-blocking の 1 点もあわせてご検討ください。

非常に正確な指摘であり、この PR がマージされた場合は、コメント投稿者による貢献、つまり props として計測されるかもしれません。しかしこのコメントが、単純に「この PR をレビューして」と AI に依頼した結果であり、投稿者自身が何もそのコメントを精査していない場合、果たしてそれは投稿者自身による貢献といえるのでしょうか ? 個人的にはそうは思えません。

AI ツールによるレビューは非常に強力で便利ですが、現時点での WordPress では、AI が唯一のレビュー担当者になってはいけません。

  • AI が生成したレビューについてあなた自身が理解し、その変更の必要性を説明できますか ?
  • そのレビューに基づいて PR が更新された場合、最終的にあなたは自信をもってその PR を承認する責任を負えますか ?
  • そのレビューは人間が読みやすいですか ? 一つのコメントにまとめるよりも、レビューを分割してインラインでコードにコメントを追加したり、suggestion を活用したり、動画・画像を添付したほうが分かりやすくありませんか ?

まとめ

AI の発達によって WordPress にコードでより貢献しやすくなった今、大事な事はつまり、以下二つに集約されると思います。

  • 常に疑問を持ち、仮設を立てること
  • 相手が人間であることを意識すること

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です