記事 Hiroshi Sato · 2 hr 前 3m read

Claude CodeでEmbedded Pythonプログラミング ちょっとしたわな

Claude CodeはIRISのことかなり理解してくれていますが、それでもやはり想定外が発生します。

まず1つ目は既に何回か発生した問題で、正しく指示しないと今後もよく発生する可能性の高い問題です。

IRISの文字型のデータ(%String)のコレーション(照合)は、デフォルトではSQLUPPERとなっていて、その結果としてデータをSQLで取得すると大文字に変換されて返ってくる場合があります。(GROUP BYなどのソートして集計する場合)

それを意識せずに(通常誰も意識していないと思いますが)、Claude Codeにそのデータの値に依存するような指示を与えると、期待した結果が得られないことが起こります。

例えば、何々のカラムの値がSupportという条件のデータを抽出するという指示を出した場合に、SQLクエリの結果の判定を = 'Support'

という条件でコーディングしますが、実際に返ってくる値がSUPPORTとなっているためにマッチしないという感じです。

Claude Codeのスキルにこれをちゃんと記載するか、クラス定義のCOLLATEをSQLSTRINGに変更することでこの状況を回避できると思います。

もう一つ最近遭遇した問題は、これはさすがに難しいだろうという感じのものです。

IRISにはご存知の方も多いと思いますが、計算フィールドという非常に便利な機能があります。

これは便利な反面、柔軟性がありすぎて意識していないとSQLの世界から見ると、そんなのあり?という局面に陥ることがあります。
今回問題となったのは、以下のような計算フィールドでした。
 

Property ReportMD As %Integer [ Calculated, SqlComputeCode = {set {*} = $translate($justify({ReportMonth},2)," ",0)_$translate($justify({ReportDay},2)," ",0)}, SqlComputed ];

月日をMMDD形式に整えるための計算フィールドで印刷の都合等で桁を4桁固定にしています。

例えば3月3日は、0303という表現形式です。

ここで問題は、型を%Integerにしている点です。

(%Integerにした理由は、以下に書いている通り、大小比較をしたかったからです)

物理フィールドであれば、データの挿入時に0303というデータをそのままの形式で入れようとするとバリデーションエラーになりますが、計算フィールドの場合は、コードでどのような形式にも変換できてしまいます。

そして問題が発生したのは、この計算フィールドを使って日付の大小判定をするSQL文をClaude Codeに生成させた時でした。

Claude Codeが生成したコードで正しく処理できなかったため、修正依頼を再度行いました。

そうすると、Claude Codeは今までにないくらい時間をかけて、最終的には与えられたリソースを使い果たし、これ以上継続できない旨知らせてきました。

そこで、生成したコードにデバッグコードを仕込んで調査したところ、生成したSQLでは意図した結果が得られていないことが判明しました。

そして原因を究明していくと、

where (reportmd >= ? and reportmd <= ?

という条件が意図した通りに動作していませんでした。

SQLの世界で考えれば、0401は数字ではないので、これは妥当な判断です。

そして解決策は、どうだったかというと

where (+reportmd >= ? and +reportmd <= ?

という数値化を強制する構文(+を先頭に付加する)にする

ということでした。

これはさすがにClaude Codeがいくら頑張って考えても原因を見つけるのは難しいでしょう。

(リソースを使い果たした理由がやっとわかりました)

これは元々の定義に潜在している曖昧性が根本原因ですので、生成AIにコーディングさせる際には、事前に意識して、こういうことが起こらない方向性を模索する方が良いような気がします。

いずれにしろ、まだまだ想定外のことは色々起こりそうですが、1つ1つノウハウを蓄積できればと思います。