🐈

AI が解決してくれなかったものたち 2025

に公開

先日のこぼれ話。2025-08-14 時点です。

https://zenn.dev/kkzk/articles/2025-08-12_use-github-copilot-agent

私の学びが誰かの役に立つかは怪しいのですが「上手は下手の手本、下手は上手の手本なり」という言葉もありますので。

case 1: Wails / メッセージボックスの戻り値

該当箇所はこちらです。

alt text

ドキュメントを読むと大丈夫な気もしますが、

alt text

特記事項がありました。

alt text

コードを書かせるだけじゃだめで、デバッグ実行できる環境を用意してブレークポイントを設定してみて気づき、そこで初めて自分でドキュメントを確認しました。

これもまた、値を yes No と文字通りに AI が解釈するのか、それとも はい いいえ のように受け取ってしまうのか。難しいところではあります。

今見直すと Option の指定も無駄かもしれないですね。こういう誤ったコードを市井に残さず、正しいコードが増えていけば何年か後には自然に治るのではないかと予想しています。それとも、自分でデバッグしてみる Agent が働くようになるほうが先でしょうか?

ともかく、これは手で直しました。

case 2: CarryOutApproval / 自分の無知

AI も頑張って要求をかなえる方向で答えを出そうとします。その要求がどんなに方向違いであっても、個人情報やセキュリティ、安全を脅かす情報でない限り。これが未熟者を苦しめます。


アプリケーションを使うユーザを自分のアプリケーションで持つと、ユーザを管理する業務が増えてしまいます。障害が起こってほかの何が飛んでも、アカウント情報が飛ぶのは特にメンドクサイ(金はもっとメンドクサイ)。そこでほかの人が保守している ActiveDirectory がある前提で、ユーザ認証はその AD DS に任せてしまうように指示を出しました。

  • テストしたいからこのアプリケーションの中に LDAP でアクセスする mock を作って

    DLAPにアクセスするための API ゲートウェイ的なものが出来上がりました。

  • そうじゃなく、あとで AD DS に置き換える前提のテスト接続先の環境を作ってほしいんだけど。Django じゃなくていいから。

    Python で作り始めて、 python-ldap(古い)や ldap3 で混乱してなかなか作り終わらない状態になりました。

  • うーん、podman とか WSL とか Hyper-V とかのほうがいい?

    それぞれ対応する案を出してくれましたが、最近の若い人は Windows しか使えないから Linux のシステムが来ると大変だという説があったので、費用が掛からずライセンス的に無難そうな podman での環境をそろえてもらいました。出てきたのは OpenLADP と phpLADPadmin のコンテナでした。まそりゃpodmanで、って言ったの私だし。

  • phpLDAPadmin から OpenLDAP につながってないみたいなんだけど?

    特権ポートを避けて OpenLDAP のこのコンテナが 3368 ポートで上がってる。こっちは環境変数で変更可能なのに、phpLDAPadmin のほうは接続先ポートを変更する設定がそのコンテナに用意されてない。という調べがつくまで、うろ覚えの podman の操作を学習するターンに。

  • うーん、接続できたの良いけど、スキーマが違うような、、、。ログインするときに DN って全部指定しないとだめだっけ?

    『そうです。全然違います。 Samba 4 なら互換です』

    おいw

  • じゃぁもうベースのOSは何でもいいから、自分で立ち上げて。phpLDAPadmin もなんか画面イメージからして長く使うのアレだから、シンプルにコマンドで管理する方針でいいや。テストユーザの一括登録ができればデータ調整は丸っと差し替えでいいでしょ。

    『できました!』 → samba-tools がなくて上がりません

もうずっと本来やりたかったことと関係ないことしてるな。もう Windows Server の評価版とかを使う前提にしたほうがいいか? Hyper-V は、、、あ、この Windows のエディションじゃだめか。VMware かぁ。どっちにしてもダウンロード時の入力フォームがなぁ。

あれ?ここに金払ってるくらいだったら、もう AWS 上に Windows Server 上げてもいいんじゃない? という結論になり、AWS を使いました。

(AWSもまだ無料期間中の初心者です。)

case 3: CarryOutApproval / 新しい製品仕様

どうしても LDAP で bind 時に strongerAuthRequired で進めない。LDAPS にしろとか言われるが、「ほかの人が保守している ActiveDirectory」で証明書の運用とか突っ込みたくない。 前はあまり考えずに、アカウント持ってればつながったような気がするんだけどなぁ。グループポリシーの設定だって、AIがいう通りに変えてる(ていうかデフォルトのまま)なんだけど。。。

メモ. Windows Server 2025のActive DirectoryではLDAP署名が既定で必須に!

あーーー。 2025 だ。

これにたどり着くまで、何度もデバッグログを出しては読み込ませ、変わらぬ状況に「ポリシーの設定が」を提示され、かなりのリクエストを消費したはずです。たぶん、最終日に急にプレミアムリクエストのペースが上がってるのはこれが大半なのでは。

詳細等は参照先記事で私も勉強中ですが、端的に今の開発(遊び)では AI にコーディングしてもらうほうに注力したいので

Windows Server 2025からの新しいポリシー設定「ドメイン コントローラー: LDAP サーバの署名要件の適用」を無効にする

にしました。

おわりに

コードのほうはそろそろフレームワークの使い方(使われ方?)を勉強する段階。「どうしてこの処理が必要なの?」という質問が増えてきました。いろいろ経て、AI への指示の質を高められればいいなと思っております。

Discussion