すごいと思ったこと。†

雑に「xxxxみたいなことしたい。コード提案して。」みたいな指示でも、無難なコードを出してくれる。

そして加えて、それを試してみた結果「xxxというエラーになってる。修正して。」と、これまた雑な指示でも相応に修正したコードを出してくれる。

これは、すごくお手軽で、強いと思った。

あと、個人的に大ヒットだったのは「正規表現式の構築」かな。
これは賢かった。
今までは自分でこちゃこちゃ作って動作確認・デバッグしてたところ、結構複雑な条件でもきちんと出してくれるのは強い。

危ないな、と思ったこと。†

ともあれ「雑な指定」をしていると、やっぱり雑なことが起こる。

特に「修正して」系の指示は、直近の問題点はそれなりに的確な提案をしてくれるんですが。
それを繰り返していると「少し前に直した問題」を忘れて、元のバグを再発させてしまうことが多々あった。

相応に厳密な指示を出してやれば、よくなることもあるんですが・・・
それすらも、うまく反映してくれないことが多々ある。

感じたこと。†

ソフトウェア開発のあるある的な話なんですが。
基本的に「うまく動いている部分には極力触らず、追加していく」ようなかたちで開発を進めていきます。

それがゆえに「屋上に屋根を重ねる」かたちになりがちで、結果、後からみると大変なことになりがち。

対してAIの場合、そういうしがらみを考えずに「一からソース書き出す」感じなんです。
だからある意味で「最終的に求めている形」に適したかたちになってはいるんですが。
同時に、「以前動いていた機能だから、今回新たにチェックしなくて大丈夫だろう」が通用しないんですね。

これ、職業としてソフトウェア開発やっていた者としては結構悪夢。
ソフトウェアの規模が大きくなればなるほど、「全機能動作をチェックする」なんてことはやらなくなります。
製品の持つ機能を全部検査するには、何人日みたいな、数十・数百時間が必要だから。
例えばたった１つの機能を追加しただけなら、その機能まわりだけの検査で済ませたいわけです。

感じたこと、その２．†

これ、いわゆる「翻訳アプリ」にも通じる気はした。

翻訳アプリも「完全にべたべたな自然言語」を入力すると、結構微妙な翻訳がでてきます。
だからある程度文脈を整理して、短文・単文の入力して「より自然な翻訳を導く」ようにするとか。

Viveコーディングも同様で。
大きな仕様を突っ込むと、微妙なモノが出てきがち。
徹底してモジュール化して、そのモジュール単位で作るとかすれば、よさそう。

もしかしたら、の話。†

前述のように、友瀬が今回触ったのは GeminiAIで、別にコーディング専門のAIではないです。
だから例えば「Claude Code」みたいな有償AIだと、より賢く・変わってくるところもあるかもしれないです。

またGeminiAIでも。
例えば厳密な仕様書を自然言語で記述したら、相応にきちんとしたことをしてくれるかもしれない。

まあ正直、あくまで友瀬は「趣味の日曜プログラミング」をやっている身なので、そこまでやる気もないんですが。

ともあれ。†

一年ほど前に書いた直感は、少なくとも現在・GeminiAIでは正しそう。

「どんなことをやりたいか（要求分析）」「どんな仕組みでやりたいか（アルゴリズム構築）」くらいまでは人間が責任もってやらないと、暴れてしまってたまらない。
そこまで落とし込んで「具体的にどう実装するか（コーディング）」を依頼して。
出てきたコードが「考えていたアルゴリズムからずれていないことを検証」する感じが、今は必須な感じ。

繰り返しますが、日曜プラグラマーレベルなんで、こんな温度で今後も付き合ってみようかと思います。

ご意見などがあれば。

仕様と問題点について†

改めて、前提となる話を。

regionプラグインは、いわゆる「折りたたみ」を実現するためのものです。
折りたたみなので、その折り畳み対象となる範囲を指定する必要があるわけです。

で、region系プラグインの実装パターンの１つが

• regionプラグインで、「開始点」を指定。
• endregionプラグインで「終了点」を指定。

・・・というかたちです。

このやり方、明確なんですが・・・ここで問題となるのが「このペアを管理する仕組みがない」ということ。
論理的に言えば「開始点」と「終了点」とは必ず１対１対応するわけですが。
pukiwikiのエディタやプラグイン自体にこれをチェックする仕組みがない。
結果、ありがちなミスとしてどちらかをより多く書いてしまう、ということが起きます。

そうすると、htmlレベルで不整合が起きてしまい、画面デザインがめちゃくちゃになりうる。
単純な見た目だけならともかく、例えばボタン類が表示されない状態になってしまい操作不能になったりするケースもありえる。
これはよろしくない。

すでにある回避策：マルチライン引数と、でも問題点。†

pukiwikiには、マルチライン引数という機能があります。
これによって例えば以下のように記載することができます。

#divregion(タイトル) {{ // ここが開始点になる
　本文
}} // ここが終了点になる

これによって、もし適切な終了点がなければこの「折りたたみプラグイン」自体が引数エラーで止まるので。
前述のような「レイアウト不良」を引き起こさないというメリットはあります。

ただ、このマルチライン引数、いわゆる入れ子構造に弱いんですね。
入れ子にする場合 {{ のようにして指定している部分、カッコの数を増やして対応付けを示さないとならない。
それこそLISPみたいな、面倒さがでてきてしまうのです。

で、今回の対応について。†

ものすごく単純にいうと。
divregion/enddivregionの各プラグインで「自分が何度呼ばれたか」をカウントして。
ページ全体で整合取れればいいよね、という発想をしました。

実際には、divregionプラグイン側で管理するメカニズムをもって。
enddivregionプラグイン側は「divregionプラグインにお伺いを立てる」ようなかたちにしました。

• divregionプラグインは、自分が呼び出された（折りたたみ開始指示をうけた）ら、カウントアップ。
• enddivregionプラグインは、自分が呼び出されたら divregionプラグインに状況を聞く。 divregionプラグインは・・・
  • 今残っている開始点が1以上あるなら、普通に「終了点を作ることを許可」する。
  • 今開始点が残っていない状態で「さらに終了点を作ろう」としているならば、「却下」する。
    その際ついでに「閉じすぎ」警告をだす。
    • これにより「終了点が多すぎる」状態を記述者に気づかせ、かつhtml構造破綻を阻止する。
• enddivregionプラグインに機能追加：「ページ終端・折りたたみクリア」モードを指定できるように。
  • このモードであっても、状況自体は divregionプラグインにお伺いを立てる。
    divregionプラグインは・・・
  • 今開始点が残っていない状態で「さらに終了点を作ろう」としているならば、「却下」する。
    この場合、通常モードと異なり警告表示は出さない。
    • この挙動があるので、実際に開始点を一つも作っていない状態であっても「常に文末に折りたたみクリアモードのプラグインを書いておく」ことができる。
  • 今残っている開始点が1つだけなら、これも普通に「終了点を作ることを許可」する。
  • 今開いている数が２つ以上なら「開始点が多すぎる」と判断。
    「多い回数だけ終了点を余計に追加」する挙動と同時に、「終了点不足」警告をだす。
    • これにより「終了点が少なすぎる」状態を記述者に気づかせ、かつhtml構造破綻を阻止する。

正確にいうと、上記以外に「マルチライン引数での書式なら」とか「グループ指定用の記述なら」みたいな例外処理がいくつかあるんですが、そこはまあ。

折りたたみクリアモードは、折りたたみでは入れ子構造があるためにいれた仕組みです。
１つめの終了点指定の前に2つ目の折りたたみ開始要求が来てもおかしくないので、単純に「閉じてないから駄目」じゃだめで。
どこかで「ここでおしまい」的な指示をしてもらわないとならなかった。
正直ちょっと微妙で、他になにかうまい手がないかなあとも思ってますが・・・とりあえずは。

とまあ、そんな感じ。

ご意見などがあれば。