なんとなくふと、Reddit共同創業者のアーロン・スワーツを思い出します。きっと彼が切に望んでいた変化だったのでしょうね……

エージェントフレームワーク……名前は大げさだけど、結局はLLMに渡すための道具にすぎない。中身のない抜け殻だ

strcpy の代わりに snprintf を使うのが正しい。コードに strcpy があるなら、それを作った開発者の所在地を突き止めるべきだ。

Railsはconventionを強制し、抽象化レイヤーの下で多くの魔法を使うので便利ですが、そのぶん性能が落ちるというトレードオフがあります。ただ、これは今すぐお金が出ていく話ではない一方で、
モデルをフレームワークが勝手に選ぶことでトークン使用量が爆発したら、その責任は誰が取ってくれるのでしょうか……？

規模に関係なく、リスクはAIで代替できないというのが私の考えです。従業員であれCEOであれ関係ありません。リスクを負っている従業員をAIで代替すれば、そのリスクは別の誰かが引き受けることになります。CEOも同じです。AIで代替すれば、別の誰かがそのリスクを引き受けなければなりません。そして結局、その人がCEOの役割を担うことになるはずです。

私は、リスクを負うのは「人間」だけだと考えています。

しかし、それをAIで代替できると言う点、しかもCEOの最大の存在意義である「非常にリスクの大きい意思決定」を行う人を代替するというので、私は疑問を抱いたのです。CEOは代替不可能で、従業員は可能だと言っているわけではありません。

ただ、近い将来には技術がそのリスクさえも分散・調整・ヘッジできるようになるとは思います。これまでも技術の進歩の方向性はずっとそうでしたから。

kime入力メソッドをおすすめします

日本語入力システムがものすごく使いづらくて実用にならなかったんですが、最近はかなり良くなりましたか？ Chrome だと入力が取りこぼされたり、最後の文字が消えたりする問題が深刻だったんですよね。

鋭い指摘です。人間のほうがエラー率は高いですよね..

これは25年前にゲーム会社に勤めていた頃、デバッグコードとしてやっていたやり方でしたが、strcpyだけの話ではないでしょう。リリース版では速度向上のために再び制限を外した状態でサービスされていました。実際、ゲーム業界はメモリ衝突に最も敏感なので、作業も非常に慎重に気を引き締めて進めていましたし、メモリデバッガも独自に作って使っていました。ところが今日になって振り返ると、それはガベージコレクションを作っていたようなものだったのです。ほのかな思い出ですね。

なるほど、興味深く読ませていただきました。追加検証を信頼度に基づいて実施するかどうか判断するとおっしゃっていましたが、この信頼度がどのように測定された値なのかも気になります。

ちなみに、gpt-4o-mini モデルは画像入力時の入力トークンがかなり高価なので、他の軽量モデルも検討してみることをおすすめします！

VLMを使って問題をうまく解決した記事ですね。興味深く読みました。

記事を読んでいて1つ気になった点があるのですが、

2. YOLO検出 – 主役オブジェクトだけをクロップして分析範囲を縮小

このプロセスはどのように組み込まれたのか気になります。

記事を読みながら、VLMのほうがYOLOより性能が良いはずなのに、むしろクロップするとYOLOモデルが誤判定して、VLMに渡す前に重要な情報が失われる問題があるのではないかと思いました。

クロップはどのような課題をきっかけに考えるようになったのか、また、どのように精度を検証して導入されたのか気になります。

おお、見栄えがいいですね。さまざまな言語に移植されるといいですね！

構造問題への変換して解いたというより、新しいモデルを作られたのではないかと思いますね

一部のハイエンドMCUでは、ご指摘のとおり、MPUを通じてアクセス権限だけでなくキャッシュ関連の属性も領域単位で設定できます。次のSTの資料がよい参考になると思います: https://community.st.com/t5/stm32-mcus/…

ただし、この記事で使用したESP32-S3では、汎用CPUや一部のMCUで提供されているような、メモリ領域ごとの cacheable / non-cacheable 属性をMPUや類似のメカニズムで設定する方式は提供されていません。

ESP32-S3の場合、外部メモリ（Flash/PSRAM）はキャッシュ/MMUを経由してアクセスするよう設計されており（TRM 4.3.3 External Memory）、アクセス権限の制御はPMS（Permission Management System）によって行われますが（TRM Chapter 15）、この機能はアクセス保護のためのものであり、キャッシュ経由かどうかやアクセス経路そのものを変更する役割はありません。

TRM（Technical Reference Manual）リンク: https://documentation.espressif.com/esp32-s3_technical_reference_manua….

エラー C4996 'strcpy': この関数または変数は安全でない可能性があります。代わりに strcpy_s の使用を検討してください。非推奨警告を無効にするには、_CRT_SECURE_NO_WARNINGS を使用します。詳細はオンラインヘルプを参照してください。

MMUはありませんが、MPUでメモリ領域とそれに対する属性を指定することはできます。
一度検討してみるとよいと思います

大きな影響力と、それに伴う高い報酬を多く得ることはあるでしょうが、それがそのまま「会社で唯一、能動的なリスク」を負う人と同一視できるわけではありません。抜擢した人が大株主かどうかによっては、なおさらそうではありません。

同じ文脈で言えば、社員は小さな影響力を持つため小さな責任を負い小さな年俸を受け取るのでしょうが、同様に能動的な責任を負う従業員でもあり、CEOもまたAIに代替されない理由はありません。

最初のコメントで述べられていた論旨は、CEOは能動的なリスクを引き受ける唯一の人であり、だからAIで代替することはできない、というものではなかったですか。

あまり使い道がなさそうだけど……

ああ、汎用コンピュータと違って、ESP32のようなMCUではメモリ属性をページ単位でランタイムに変更できるMMUが提供されておらず、cacheable / non-cacheableかどうかはあらかじめ決められたメモリ領域単位で決まっているため、おっしゃるような使い方はできないんですよね（内部SRAMはnon-cacheable、PSRAMはcacheableメモリとして一括で固定されています）。

良い質問をありがとうございます！

わあ、これを配るんですね……本当に恐ろしい会社です