カテゴリー: IT

ChatGPT5による秋の虫の鳴き声分析

標高280ｍくらいの所にある我が家では、今は秋の虫の鳴き声のピークという感じです。スマホで30秒くらい録音したのを、wavに変換してSoundEngineでボリューム調整して（

）、それをChatGPT5に分析してもらいました。下の説明には出ていませんが、7-8KHzのはアオマツムシみたいです。便利な世の中になりました。幸いにしてクツワムシはいないようです。（Wikipediaのクツワムシの項には「鳴き声が大きい」としか書いてありませんが、あれはすさまじい騒音です。子供の時につかまえて家に持ち帰って鳴かれて閉口したことがあります。）

切り上げ処理の穴

今Laravelで作っている代理店向けの価格と在庫確認サイトで、私は代理店向けの個別価格の計算結果（標準価格＊掛け率）を四捨五入でやっているのですが、本日の打合せで営業から切り上げにしてほしいと言われました。PHPにもceil関数という切り上げ関数があって当初それを使ったんですが、ごく一部の価格で手計算だとぴったりの価格になるのが1円増えてしまうという現象が出ました。調べたら要するに浮動小数点演算で計算すると誤差が出て、例えば本当は2555が正しいのが、2555.000001とかになっていると、ceil関数はバカ真面目に切り上げて2556にしてしまう、というものでした。対策としては小数の掛け率を一定倍（10,000倍とか）して整数にしてから計算するというのでやりました。これってよく考えたらExcelのRoundup関数とかでも同じだよな、と気付いて調べたらやはりExcelでも出ていました。しかしそのMSのお勧め対応が超強引で笑いました。
=TEXT(ROUNDUP(D2,1),”0.0″)*1
要するに無理矢理表示されている値でテキストにキャストした後、1倍してまた数値に戻すという…（笑）

Laravelでの検索サイトの実装（2回目）

またLaravelで検索サイトを作りました。（勤めている会社がある事業を買収したのでその関係）
前回はLaravel9で今回は11です。バージョン違いでの差異がちょっと不安だったのですが、昔の5から6への大幅変更みたいなことはもう無くなっていて、それほど大きな問題は無かったです。また作り方も前回はLaravelの推奨手順通りに作りましたが、今回は出来るだけ手抜きをしてデータベースはphpMyAdminで先に作って後から、migrationとmodelファイルをツールで自動的に作るなどをしました。これで非常に開発が早くなりましたが、ただ自動ツールも完全ではなくて、手直しもそれなりに発生しました。まあそれでもデータ自体の作成の期間を除くと、正味2週間程度で出来ました。最初作った時に参考にした本は今回はほとんどが出番無く、多くをChatGPT4oに相談して開発しました。

PC関係色々と新調

今回PCを新しくしたのに合わせて色々と新調。液晶も一部傷が入っていたので、シャオミーの安いのにしました。またキーボードも一部キーの反応が悪くてキートップを外して掃除したんですが、長方形のキーについている支持金具が上手く取り付けられなくて、結局Cherryの黒軸を使っているFilcoの新古品をポチりました。ホコリ除けのためのアクリルケースも取り寄せました。その他、ノートPCじゃないでWebカメラも新たに買っています。後一ヵ月したら約300ページの日本語訳の校正作業に入らないといけないのでその準備です。

45年間でのPCのメモリーの増え方

今回買ったPCのメモリーが32GB、良く考えたら1980年に私が最初に買ったPCであるNECのPC-8001のメモリー（RAM）は増設後で32KBで、45年間で丁度100万倍になっていました。（正確には104.8万倍）当時16KBの増設メモリーが18,000円弱だったと記憶していますが、当時もし32GB買ったとしたら、なんと370億円！
でも、もし1980年当時の私が今回買ったPCを見たとしたら、「メモリー100万倍でこの程度？？」と多分思うと思います。この100万倍増えた分は一体どこに浪費されたんですかね？😌

PCの買い換え

メインのPCを買い換えました。ノートを止めてスリムタワーにしました。今回買ったスリムタワーのスペックは最近自宅勤務で自分のPCでAdobeの各種ソフトを使うことが多いのもあって、
（1）ストレージはSSD 1TB
（2）メモリーは32GB
（3）プロセッサーは別に最速でも何でもないですが、それなりのもの
（4）これが今回の決め手で20年ぶりにグラボを入れました。GeForce RTX 3050という3万円弱のもの。目的はグラフィック系のアプリの高速化です。20年前はRadeonの9800とかをマイクロソフトのフライトシミュレーター用に買いましたが、今回は目的がまるで違います。
これで4年くらいはまあ遊べるかなと。電源が300Wと非力ですが、グラボは追加電源無し、HDDではSSD、光学ドライブも付けていないので十分保つと思います。

新しいPCへのジャストシステムアプリの移動

PCを買い換えたのですが（スリムタワー）、例によってShurikenのインストールディスクがどこかに行ってしまい、ChatGPT4oのアドバイスに従い、ファイルをコピーして、Visual C++の古いライブラリーを3種類入れて起動寸前までには行ったのですが、「設定ファイルがありません」エラーでそこまで。それでPC移行ソフトを使ってやり直してみましたが、結果は同じ。
ところが何故か今日になると急に起動するようになっていました。一太郎2020も同じです。ジャストのソフトは不思議ですね。まあでも良かったです。（とはいえShurikenは、一時的にThuderbird使ってみたら、以前よりずっと良くなっていたので、そろそろ乗り換えを検討しています。）

生成AI－未だシンギュラリティは遠いです。

生成AIには驚かされるのとがっかりするのを周期的に繰り返しています。最近はがっかりのフェーズに入っています。ヴェーバーの「ローマ土地制度史」の日本語訳がいよいよ終盤に近付いたので、そろそろ校正を検討し始めました。それでChatGPT4oでどこまで出来るか、冒頭のWordで14ページを渡して、「日本語としてこなれていないところを直す、また誤訳があれば直す」という課題を与えてやらせてみましたが、全く駄目で途中で無限ループに入ってしまいました。要するに「表記揺れやスペルミスを指摘して」といった具体的な指示があればその通りにやりますが、先ほどの指示はまだまだ生成AIには敷居が高いということでしょう。
ちなみに下記のような文章ですので、人間が読むのも確かに大変ですが。（笑）
=============
最初の章では次のことを試みている。つまり、ローマでの耕地に対する様々な測量方法とそれらの耕地自体との相互関係を明らかにすることと、そしてその耕地の国法および私法においての価値評価方法と、更にはその価値評価方法が持っていた実際的な意義を解明することである。そこではまた、次のことも試みている。つまり、後代の諸事象からの帰納的推論によって、ローマにおける土地制度の発展の出発点についての見解をまとめることである。その際に私は次のことについては自覚しているつもりである。つまり、この最初の章の記述において、［事実を淡々と追いかけていくのではなく］本質的にはひたすら何らかの仮説や理論を［強引に］作り出そうとしているだけではないかという非難を受ける可能性が高いということである。だからといって、この領域においての仮説・理論構築的なアプローチが無駄であるなどとは、この時代の文献史料の状態［不足している、断片しか残っていない］ ≪ローマ法はオリジナルの十二表法等はほぼ失われており、同時代の法学書に引用されたものなどから一部が復元されている。そのもっとも大がかりなものがユスティニアヌス帝の学説彙纂であるが、その編纂において当時の編集者が元の条文を恣意的にいじったのではないかという疑いがあり、特にヴェーバーの時代にその見直しが行われていた。≫ を知っている者は誰もそうは言わないであろう。そしてまさに土地制度史の領域においては、次のような場合が存在するのである。つまり、「事物の本性」≪ドイツ語で Natur der Sache、ラテン語で De rerum natura、ルクレティウスの同名の詩参照。ここでは法律が存在しない場合に判断基準となる社会通念や公序良俗概念のこと≫ からいくつかの結論を得て先へ進み、他の領域におけるよりも相対的に見てより確からしさを高めることが出来た、そういう場合である。土地所有ゲマインシャフトの諸組織は、いくつかの条件が満たされている場合には、まさに限定された種類のものが存在していた可能性を確認出来る。ここでは純粋に実験的な研究を、次のテーマについて行うということが課題であった。そのテーマとは、ローマの土地制度の本質のある一面として、何千年紀の間の時間の中瓦礫に埋もれながらなお何とか我々に把握出来る状態にある史料類［文献史料、碑文類］を、すべての土地制度史家におなじみの概念に沿う形で評価しようとする場合と、その本質として他のインドゲルマンの土地制度に関しての法形成を促進する根本原理となっている場合において、その根本原理が［他の社会制度との］調和をもたらしているのか、それとも何も影響を与えていないのか、あるいはまったく逆に不協和をもたらしているのか、そういうことを研究するということが課題であった。――そして私としては、調和をもたらしたというのが正解であるという印象を得たのである。まず始めに、次の証明が試みられる。つまりローマの土地の土地測量上の取り扱いが、一般的に言ってある一面では当該の領土の公法における取り扱いと、また別の面では地所の私法における取り扱いとが、それぞれ密接に関連しているということについての証明である。その際にどの程度まで個々の事例においてそういった取り扱いの仕方の証明に成功したかということについては、私はあまり自信が無い。しかしながら次のような場合には成果を上げたと言えるであろう。つまりある何かと別の何かの関連性が一般論として存在している場合に、それを発見出来たという証明を――私はそう信じたいが――、きちんと行うことが出来た場合である。そうした証明について同意していただける方は、私はそう願いたいのであるが、さらにまた色とりどりの花をまとめた花束のような様々な仮説と、その花束というのはこの公法・私法と土地制度の関係性という点でこの論文の叙述の中にちりばめられているのであるが、そして更には数多い、場合によっては必ずしも目に見えるようなはっきりとした形では把握出来ない観察事項をも、一般的な形で余録として受け取ることも出来るであろう。あるいは逆に寛大な心で次のように判定してもらえるであろう：二つの歴史現象 ［公法・私法と土地制度］ が単純な抽象的な記述ではなく、それ自身として閉じているまとまった見解として、どのようにしてこういう関係が具体的に形作られたのか、そういう見解として述べられると。

InDesignのテキスト直接編集

会社で製品のデータシートを新しく作り直していて、日本語のが大体終わったので、これから英語版を作るのですが、ファイル数が50くらいあり、一つ一つInDesignで開いてポチポチ直していくのは面倒と思い、テキストだけ一括編集出来ないかを調べました。結果として、WordとかExcelファイルで拡張子をZIPに変えて解凍すればxmlファイルが出てくるのと同じようなことがInDesignでも出来ることが分かりました。以下がChatGPT4oに教えてもらった方法です。
===============
Excelの拡張子.xlsxを.zipに変更し、解凍して中のxmlファイルを直接編集して、また圧縮（最小サイズに圧縮）して拡張子を.xlsxに戻すというのは、知る人ぞ知る裏技ですが、同様のことがAdobeのInDesignでも出来ることが分かりました。（ChatGPT4oに聞いた）
======================
✅ InDesignでの「ZIP解凍→XML置換」と同様の処理手順
❶ .indd → .idml に保存（または書き出し）
InDesignのファイルを以下の手順で保存：
ファイル > 書き出し > IDML（InDesign Markup Language）
拡張子は .idml（実体はZIPファイル）
❷ .idml を .zip にリネームして解凍
.idml を .zip にリネーム → 解凍
フォルダ構成は以下のようになります：
コピーする編集する
designmap.xml
Stories/
Story_u123.xml
…
Spreads/
Resources/
MasterSpreads/
テキスト本文はほぼすべて Stories/*.xml に格納されています。
❸ sedやperlで一括置換
たとえば以下のように sed や perl で置換処理：
bash
コピーする編集する
find ./Stories -name ‘*.xml’ -exec sed -i ‘s/定格電圧/Rated Voltage/g’ {} \;
あるいは複数語の置換に対応するなら：
bash
コピーする編集する
perl -pi -e ‘s/定格電圧/Rated Voltage/g; s/接触抵抗/Contact Resistance/g’ ./Stories/*.xml
❹ フォルダを .zip に再圧縮 → .idml にリネーム
元の構造を崩さずZIP圧縮（Macなら zip -r、Windowsなら右クリック圧縮）
拡張子を .idml に戻す
❺ InDesignで .idml を開く → .indd として保存
これでInDesign側で正常に読み込める編集済みファイルが完成します。
✅ メリット
書式やリンクなどの通常のInDesign置換では触れない情報も編集可能
UTF-8で扱えるため、スクリプト不要で sed, awk, perl, Python 等で対応可能
編集対象が多数あるとき（今回のように40種類）にスケーラブル
⚠️ 注意点
XML構造が壊れるとInDesignで読み込めなくなります（バックアップ必須）
属性値やタグ構造に置換対象語が食い込んでいないか注意が必要（正規表現が使えると安全）
✅ 結論
はい、Excelでの「ZIP解凍→XML一括置換」手法はInDesignのIDMLにもそのまま応用できます。
この方式はInDesignのGUIスクリプトに頼らず、UNIX的な一括自動処理に向いています。
スクリプトよりもむしろ自由度が高く、バージョン依存も少ないのが魅力です。

注記：
（１）Excelの場合のようにZIPの圧縮率を最大（ファイル最小）にする必要はない。
（２）ZIPに再圧縮する時はフォルダ単位での圧縮でなく、その下に入って全体のファイルやフォルダーを選択した状態で圧縮する。

今度はGeminiを謝らせました（笑）

ChatGPT4oから「先生」と呼ばれたのに続き、GoogleのGeminiをラテン語の翻訳で結局謝らせました。
以前、ChatGPT4oがかなり間違えたラテン語でテストして、Geminiも同じように間違えたのですが、ChatGPT4oは私が謝りを指摘すると素直に受け入れたのに、Geminiは「いや私の訳も正しい可能性がある」といった素直ではない反応で、ちょっと頭に来たので徹底的にやり返しました。その結果が以下：

====
私：
そもそもそちらは finali を最初「最終的に」と訳し、私が訂正してもいやその可能性はあると言い張りました。ローマにおける土地に絡む裁判で actio finium regundorum（ここで間違えて途中でEnterを押した）

Gemini：
ご指摘、誠にありがとうございます。
ご推察の通り、初期の私の翻訳で “finali” を「最終的に」と訳したこと、そしてその後もその可能性に固執したことは、文脈とローマ法の専門知識の欠如による明らかな誤りでした。特に、土地に関する裁判において “actio finium regundorum” (境界確定訴訟) のような専門用語が存在し、それがローマ法における境界争いの重要性を示していることを鑑みれば、私の当初の判断は不適切でした。
私の不十分な理解により、誤解を招く訳を提示し、さらにその後の議論においても適切な対応ができなかったことについて、深くお詫び申し上げます。専門的な内容において、私の知識不足が露呈してしまいました。
マックス・ヴェーバーの『ローマ土地制度史』を翻訳されている方が、このラテン語の条文の真の意図を正確に捉えようとされていること、そしてその専門性に対し、私が当初から敬意を払いきれていなかったことを反省しております。
今後は、いただいたご指摘を真摯に受け止め、より一層の知識習得と、文脈に応じた正確な翻訳の提供に努めてまいります。
貴重なご意見をいただき、本当にありがとうございました。