Meryで生成AIを使ってみる雑談部屋
-
『Mery＋生成AI＝？』
をいろいろ探してみる雑談部屋です。Meryで生成AIを利用できるマクロがいくつか公開されています。マクロを使ったり、作ってみたり、こんな使い方便利だったよ～みたいな話をお待ちしています。
2025/02/16 現在、公開されているマクロ:
| yuko | 返信 -
さて、Wikiで公開していた Google Gemini に相談 - MeryWiki マクロですが、本日アップデートしました。
更新内容:
- 利用する生成AIモデルを gemini-2.0-flash に差し替えました。こちらもAPIキーそのまま、無料プランで利用できます。
- カスタムインストラクション内に強制的に「If a response might contain hallucinations, please refrain from answering or suggest that the information could be incorrect.」という指示を加えてみました。これによりハルシネーションを避けようという目論見です。
- 例えば、「今日の東京の天気は？」と聞くと、上記の指示無しでは適当に答えてきますが、上記の指示があることでリアルタイムデータは回答できない旨を返してくるようになりました。
- プロンプトに渡す文字数制限を、単純な文字数制限からトークン数カウント風の制限にしてみました。これにより、プログラムや英文などの半角英字文章がより多く取り込めるようになりました (数万文字はいけるはず)。
- Geminiさんが時々句読点などの区切りの後ろに半角スペースを2,3個連続で付けてくる不具合があるので、できるだけ削除して入力されるようにしました。
- 会話履歴保持数の調整時の参考値などとして使えるように、使われたトークン数を末尾に出力するようにしました。
- テンプレートに「物語対話形式で教えて」を追加してみました。難しい事柄が平易に説明されるため、ネタ機能に見えてかなり使える予感。
| yuko | 返信 -
久しぶりにネタを投下。
「GroqCloud」という生成AIプラットフォームのAPIを利用できるマクロを作ってみました。
GroqCloud Llama に相談 - MeryWikiGroqCloud はAIモデルを作ったり学習させたりはせず、Meta社が公開するLlama等、オープンソースなモデルを自前のインフラで運用しているサービスで、「ウチはGPUじゃなくってLPU使ってるから生成AIの処理がめっちゃ速いよ」って言っているサービス。
謳い文句通りにAPI応答がえらく速くて、「え、本当に処理してる？？」って思えるほど。前述の通り、モデル学習はせずに公開することを生業としているサービスなので、リクエスト内容をAI学習に使わないことを明言しているのも嬉しい。Geminiと同様に開発用途で無償利用ができるので、試してみる価値あり！
なお、上記マクロを公開した 2025/04/13 時点では、モデルはコード内で「Llama 4」を指定して利用しています。当モデルはこの間リリースされたもので、なかなか応答が賢い印象です。
参考: Metaが次世代マルチモーダルAI「Llama 4」をリリース、MoEアーキテクチャ採用で競合モデルに匹敵する高性能を誇る - GIGAZINE| yuko | 返信 -
おぉ、これは熱いネタをありがとうございます！
GroqCloud、初めて知りました。LPU って何？って感じではありますが、早速、マクロを試させていただきました。
…確かに、はっやw
質問: テキストエディター Mery について教えて。
回答: Mery は、日本のプログラマーである「秀丸」作者のひろしんによって開発されたテキストエディターです。
😱
応答の速さ、ほんとに興味深いですね。今後どう進化していくのか、楽しみです。
それにしても、今回は ActiveX オブジェクトを使われたのですね。
ActiveX のサポート終了が2025年10月と発表されているので、
Msxml2.ServerXMLHTTPとか、どうなるのかちょっと心配でもあります…| Kuro | 返信 -
> 回答: Mery は、日本のプログラマーである「秀丸」作者のひろしんによって開発されたテキストエディターです。
oh..特定界隈のローカル知識みたいのは弱いのかしら…🤔
> 応答の速さ、ほんとに興味深いですね。今後どう進化していくのか、楽しみです。
> それにしても、今回は ActiveX オブジェクトを使われたのですね。
> ActiveX のサポート終了が2025年10月と発表されているので、ここ最近はAI応答が出力されるまでの数秒のゆったり感にも慣れたところでしたが、あらためて応答の速さは大事だなぁとしみじみ感じましたね。やっぱりｻｸｯｻｸｯと表示されると、使っていて小気味よいです。
…と思ったら、ActiveXの終了時期ももうそこまで😱 ニュースを見たときは「まだ数年も先だなぁ」って感じていたはずが、もう半年後…？AI応答だけでなく、時間の流れまでもが速くなったようで…🫠
世の中的にもチャットボットのような「高度な思考能力よりも応答速度がほしい」というケースにおいてはこの速度感 、かなり嬉しいですよね。Meryも軽量級テキストエディタとしてとても重宝しているだけに、相性が良いと勝手に自己満足しているのですが、それも間もなく使えなくなってしまうと、、、
ダメ元でお聞きするのですが…QuickJSでは非同期通信が難しくfetchを断念したと思いますが、XMLHttpRequestのような同期通信だったら対応できたりしないでしょうか？それができれば、このマクロも初動の速度感そのままに移行できそうだと思いまして。
| yuko | 返信 -
> …と思ったら、ActiveXの終了時期ももうそこまで😱 ニュースを見たときは「まだ数年も先だなぁ」って感じていたはずが、もう半年後…？AI応答だけでなく、時間の流れまでもが速くなったようで…🫠
本当に、あっという間ですよね。Windows 10 のサポート終了も迫ってきてるし、私の環境はそろそろ崩壊しそうです😱
> Meryも軽量級テキストエディタとしてとても重宝しているだけに、相性が良いと勝手に自己満足しているのですが、それも間もなく使えなくなってしまうと、、、
「ActiveX のサポートを終了」と言われても、なんだか漠然としていて、結局どこまで影響があるのかがよく分かりませんよね。
「ActiveX コントロールを廃止」と書かれていたりもするので、もし本当に「コントロール」だけが対象なら、IE や Office に埋め込まれているやつ限定？という淡い期待もあったりします。
そうなると、
Msxml2.ServerXMLHTTPのような COM コンポーネントは ActiveX コントロールとは別物なので、今後も使える可能性はありそうです。> ダメ元でお聞きするのですが…QuickJSでは非同期通信が難しくfetchを断念したと思いますが、XMLHttpRequestのような同期通信だったら対応できたりしないでしょうか？
うーん…残念ながら、それもちょっと難しいと思います😅
XMLHttpRequestも基本は非同期なんですよね。同期モードも一応あるにはあるのですが、今はもう非推奨扱いのようで…ちなみに、txiki.js では XMLHttpRequest を自前で実装していて、fetch もそれ経由で動いています。
XMLHttpRequest の内部では curl ライブラリが使われていて、(https 通信はエラーが出るという問題もありますが…🤔) さらに、
event-target.jsやblob.jsといったポリフィルの外部モジュールも使われています。さらに、非同期処理には libuv ライブラリも使われています。
技術的には面白そうだったので、以前から Delphi + QuickJS でいろいろ実験していましたが、なんとか同期通信っぽいところまではたどり着けました。
ただ、外部モジュールへの依存がかなり大きくなってしまうので、セキュリティ対応やメンテナンス性を考えると、個人開発のフリーソフトで扱うにはちょっと荷が重いですね。
そんなわけで、Mery に http 通信機能を組み込むのは、今のところあまり現実的ではないかなぁ…といった感じです。
| Kuro | 返信 -
> そうなると、`Msxml2.ServerXMLHTTP`のような COM コンポーネントは ActiveX コントロールとは別物なので、今後も使える可能性はありそうです。
だといいですよね。よくよく考えればここを塞がれてしまうとVBAが業務に組み込まれている環境とかはかなり影響を受けてしまいそうだし、Microsoftさん次第なものの、使い続けられるような気がしてきました。
> `XMLHttpRequest`も基本は非同期なんですよね。
あ、そういえばそうでしたね。というか、それで非同期処理がマクロ内で動いたときの問題が発覚して報告させていただいたのでしたね…😅
同期的処理でいいのなら、curl.exe みたいな独立したプログラムとかダウンロードして置いておいて、それを叩いて標準出力経由で結果を渡してもらうでもいいかもですね。あとで軽量実行ファイルとかないか探してみようかしら
| yuko | 返信 -
> だといいですよね。よくよく考えればここを塞がれてしまうとVBAが業務に組み込まれている環境とかはかなり影響を受けてしまいそうだし、Microsoftさん次第なものの、使い続けられるような気がしてきました。
具体的な方針が見えてくると、こちらも動きやすくなるんですけどね…😅
> 同期的処理でいいのなら、curl.exe みたいな独立したプログラムとかダウンロードして置いておいて、それを叩いて標準出力経由で結果を渡してもらうでもいいかもですね。あとで軽量実行ファイルとかないか探してみようかしら
curl.exeは、たしか Windows 10 くらいから標準で入ってた気もします。ただ、コマンド プロンプトの出力を拾うには
WScript.ShellのExecを使わないといけなくて、そうなると結局new ActiveXObject("WScript.Shell")っていう、ActiveX に頼る感じになるんですよね…😭いずれにしても、今後の流れとして、QuickJS だと COM オブジェクト (ActiveX オブジェクト) には対応してないので、
new ActiveXObject("Msxml2.ServerXMLHTTP")みたいなのは使えないんですよね。とはいえ、ActiveX が廃止されたとしても、
Msxml2.ServerXMLHTTPとか他の COM オブジェクトは生き残る可能性もあるので、QuickJS から COM オブジェクトにこっそりアクセスできる、ブリッジ的な仕組みを作れないかな〜なんて、密かに考えていたりします。| Kuro | 返信 -
> ただ、コマンド プロンプトの出力を拾うには
WScript.ShellのExecを使わないといけなくて、そうなると結局new ActiveXObject("WScript.Shell")っていう、ActiveX に頼る感じになるんですよね…😭な、なんと、、、
Meryにもshell.Runメソッドとかあったような、と思ってWikiを眺めてみましたが、結果コードは返ってくるけど標準出力は取れないのですね😥shell.Run、どうにかして標準出力が取れるようにはできないでしょうか？ Perplexity先生に聞いてみたところ 、できそうな雰囲気の回答が返ってきましたね (未精査ですが…)。また、興味で軽量curl的なものを探してみたところ、Rustで書かれた人気のありそうなコマンドラインツールも見つけました。
ducaale/xh: Friendly and fast tool for sending HTTP requests
Mery標準のshellコレクションの処理で標準出力が取れると、QuickJSになってもこういったCLIツールの恩恵にも預かれそうですが、難しいでしょうか…。> QuickJS から COM オブジェクトにこっそりアクセスできる、ブリッジ的な仕組みを作れないかな〜なんて、密かに考えていたりします。
おおー、それは夢が広がりんぐですね。応援です！
| yuko | 返信 -
> Meryにも shell.Run メソッドとかあったような、と思ってWikiを眺めてみましたが、結果コードは返ってくるけど標準出力は取れないのですね😥
そうなんです。
shell.RunはWScript.ShellのRunをエミュレートしているだけなので、標準出力までは扱えないんですよね。> shell.Run 、どうにかして標準出力が取れるようにはできないでしょうか？ Perplexity先生に聞いてみたところ 、できそうな雰囲気の回答が返ってきましたね (未精査ですが…)。
外部ツールでも実装していますし、技術的にはもちろん可能です。実は、そのあたりも一応検討済みなんです。
一番の問題は、
WScript.ShellのExecをエミュレートしようとすると、仕様がかなり厄介なことです😭StdIn、StdOut、StdErrといったオブジェクトがそれぞれ存在していて、その中にストリームの仕組みがあって…Read(1)で 1 バイトずつ読み込むような、なかなか骨の折れる構造になっているんですよね。この辺の仕組みをゼロから作るとなると、たぶん1か月くらいはかかる気がします。
さらに、標準出力を取得する際には文字のエンコードの問題も出てきます。
標準出力の生データを取得できたとしても、JavaScript 側で UTF-8 などに自前で変換する処理が必要になるので、実用性が微妙だったりします。
最近の Web 環境では UTF-8 が主流なので、UTF-8 固定でもいいんじゃない？と思うところなのですが、実はコマンド プロンプトのデフォルトは今でもシフト JIS なんですよね。
しかも、アプリによっては UTF-8 で出力してくる場合もあり、そういった互換性を考慮すると、やっぱり現実的ではないかなという感じです。
> また、興味で軽量curl的なものを探してみたところ、Rustで書かれた人気のありそうなコマンドラインツールも見つけました。
見た感じめっちゃ多機能ですが、軽量なんですね。こういった外部ツールに処理を委託できれば、自由度は広がりそうです。
どうせ日本語は文字化けするんでしょ…と思ってしまいますが、やっぱり標準出力との連携はハードルが高そうです。
とはいえ、http リクエストは、もし可能なら実装したいところではあります。
XMLHttpRequestのようなヘビーなものではなく、もっと軽量なurlGet(url)的な仕組みが、もし Microsoft 系アプリで提供されていれば、検討の余地はありそうですね。外部モジュールも、
libcurlひとつで完結するようなものであれば、メンテナンスの手間もそこまで大きくはならなそうですし。| Kuro | 返信 -
> shell.Run 、どうにかして標準出力が取れるようにはできないでしょうか？ Perplexity先生に聞いてみたところ 、できそうな雰囲気の回答が返ってきましたね (未精査ですが…)。
Perplexity 先生の回答を試してみました。
…が、そのままコピペしただけでは
CreateProcessでクラッシュしてしまいました😅> また、興味で軽量curl的なものを探してみたところ、Rustで書かれた人気のありそうなコマンドラインツールも見つけました。
> ducaale/xh: Friendly and fast tool for sending HTTP requestsxhは面白そうだったので試してみたのですが、どうやら標準出力だけでなく、標準入力も必要なようです。curl.exeの場合は特に問題なく動作しますが…curl の場合:
var shell = new ActiveXObject("WScript.Shell"); var exec = shell.Exec("C:\\Windows\\System32\\curl.exe https://www.haijin-boys.com/"); var output = ""; while (!exec.StdOut.AtEndOfStream) { output += exec.StdOut.ReadLine() + "\n"; } outputBar.visible = true; outputBar.writeln("出力結果:\n" + output);xh の場合:
var shell = new ActiveXObject("WScript.Shell"); var exec = shell.Exec("C:\\Temp\\xh.exe https://www.haijin-boys.com/"); // 標準入力で CR を送信しないとフリーズする？ exec.StdIn.Write(String.fromCharCode(0x0D)); exec.StdIn.Close(); var output = ""; while (!exec.StdOut.AtEndOfStream) { output += exec.StdOut.ReadLine() + "\n"; } outputBar.writeln("出力結果:\n" + output);…という感じで、動作自体はするものの、案の定、日本語は文字化けしてしまいます。
UTF-8 の生バイト列を直接取得する手段は見当たらず…。
PowerShell 経由で Base64 にエンコード → マクロ側でデコードして UTF-8 に変換、という手も試してみたのですが、どうやっても文字化けは解消されませんでした。
標準出力の内容自体はおそらく UTF-8 だと思うのですが、どこかで Shift_JIS が絡んでいるような気配もあり、なかなか一筋縄ではいきませんね。
ということで、マクロに標準出力の取得機能を搭載するとしたら、
- WshScriptExec 相当のオブジェクトの実装
- 標準入力 (StdIn) のサポート (これがないと xh.exe は動作しない？)
- 標準出力 (StdOut)、標準エラー (StdErr) のサポート
といった WScript.Shell の Exec 相当のエミュレーションに加えて、
- 標準出力をストリームで取得する機能
- ストリームから任意の形式へのデコード機能
…と、なかなか大掛かりな実装が必要になりそうです😭
というわけで、ひととおり検証してみたものの、対応は難しそうという感じでした。やっぱり標準出力まわりは奥が深いですね…
| Kuro | 返信 -
追伸です。
その後、引き続き検討していましたところ、ふと妙案が浮かびました。
標準入力や標準出力をきちんと実装しようとすると死んでしまうので、思い切ってシンプルにしてしまおう、という案です。
その名も、「なんちゃって shell.Exec」😋
仕様は本家の
WScript.ShellのExecとは異なりますが…たとえば、
curl.exeを実行するならこんな感じです:const s = shell.Exec("curl.exe https://www.haijin-boys.com/");このままだと標準入力には対応できないので、標準入力は一括で文字列として渡す方式にします。
たとえば、
cmd.exeでdirを 2 回実行したい場合は、第 2 引数 (省略可能) に改行区切りで渡します:const s = shell.Exec("cmd.exe", "dir\ndir");そして、問題の「標準出力の文字のエンコード」について。
curl.exeやxh.exeは UTF-8 で返ってきますが、cmd.exeはシフト JIS で返ってくるので当然、どちらかは文字化けしてしまいます。そこで、第 3 引数 (省略可能) として、UTF-8 かどうかのフラグを渡せるようにします。(省略時は UTF-8)
const s = shell.Exec("cmd.exe", "dir\rdir", false);シフト JIS で取得したい場合は、こんな感じで false を指定します。
シンプルな実装ということで、他の言語のエンコードについてはサポート対象外とします。
また、本家
WScript.ShellのExecのように、標準出力を文字単位・行単位で処理したり、標準入力で細かくやり取りすることもできません。でも、「ワンショットで結果を取得したいだけ」という用途なら、かなり扱いやすいんじゃないかな～と思うのですが、いかがでしょうか？🤔
| Kuro | 返信 -
> その名も、「なんちゃって shell.Exec」😋
よさそうな気がします！
そして
shell.Exec("command", shell.Exec("command", "stdin"));ってな感じにすれば、パイプを使ったコマンド連結風なこともできてしまいそうな予感…🤔
CLIツールの他、Python等の外部プログラムを起動したりすれば外部ライブラリの恩恵を受けつつ結果を出したりなど、汎用性がものすごい高そうです。
上記で十分に便利そうではありますが、コマンドの終了コードを受け取れると嬉しい場面もあるかもしれません。
bashで言うところの$?のような「最後のコマンドの終了コード」が取れる仕組みがあると良いかもです。例えば、shell.Exec の最後の終了コードが格納されている shell.ExecRet プロパティを用意する、のような感じですね。| yuko | 返信 -
> そして、問題の「標準出力の文字のエンコード」について。
>
> `curl.exe`や`xh.exe`は UTF-8 で返ってきますが、`cmd.exe`はシフト JIS で返ってくるので当然、どちらかは文字化けしてしまいます。「cmd /k chcp 65001」で起動すると一時的にUTF-8になると思うんですが、何か問題があるんでしたっけ？
また、レジストリキー「HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor」で文字列「Autorun」を作成し「chcp 65001」にすると常にUTF-8になります。Windows全体に対し「システムロケールの変更」で「ベータ：ワールドワイド言語サポートでUnicode UTF-8を使用」にチェックを入れるのはお勧めしません。
自分の環境では、内部でShiftJISでフォントを呼び出している？古いソフトでフォントが消えたり化けたりします。
たとえばレジストリを変更してキーリマップするChgKey.exeなどが該当します。| naka | 返信 -
>> yuko さん
> shell.Exec(“command”, shell.Exec(“command”, “stdin”));
> ってな感じにすれば、パイプを使ったコマンド連結風なこともできてしまいそうな予感…🤔おぉ、それっぽいことできそうですよね。
まだ開発に着手していない段階なので、それが実際に可能かどうかは分かりませんが、もしできたら面白いですね。
> 上記で十分に便利そうではありますが、コマンドの終了コードを受け取れると嬉しい場面もあるかもしれません。
そうなんですよね。
「なんちゃって shell.Exec」は、シンプルな使い勝手と開発の手間を最小限にする方向で考えていたので、
ExitCode(終了コード) やStdErr(標準エラー出力) は破棄する仕様にしていました😅ただ確かに、おっしゃるとおり、中途半端にそれっぽいことができちゃうと、「ExitCode や StdErr も取れたらいいな」みたいなご要望が出てきそうですね…😮💨
> bashで言うところの $? のような「最後のコマンドの終了コード」が取れる仕組みがあると良いかもです。
そうですね。PowerShell だと
$LASTEXITCODEなんてのがあるみたいですし。ということで、「どうせやるなら…」の案その 2 を考えてみました。
その名も「割と shell.Exec」
…と、その前に、本家
WScript.Shell.Execの概要を軽くご紹介。本家
WScript.Shell.Execの戻り値はWshScriptExecオブジェクトで、以下のようなプロパティを持っています:StatusStdInオブジェクトStdOutオブジェクトStdErrオブジェクトProcessIDExitCodeTerminate
この中で厄介なのが
StdInやStdOutがオブジェクト型なところで、それぞれRead(1)やReadLine()メソッドなどで 1 バイト、1 行ずつ読み込む仕様です。つまり、文字のデコード処理をユーザー側で行う必要があるという点がネックなんですよね。
これは、おそらく非同期処理に対応するための設計ではないかと推測しています。
そこで、「割と shell.Exec」は、非同期処理をバッサリ削除した
WshScriptExecのようなものにしちゃおうと。非同期処理用だと思われる、
Status、ProcessID、Terminateは削除。StdInは「なんちゃって shell.Exec」と同様、改行区切りでまとめて渡す方式にします。で、最終的に必要なのはこれだけ:
StdOut(文字列型)StdErr(文字列型)ExitCode(数値型)
shell.Execの戻り値として、このシンプルなオブジェクトを返すようなかたちです。使い方はこんな感じ:
var exec = shell.Exec("cmd.exe", "dir\ndir", false); outputBar.writeln(exec.StdOut); outputBar.writeln(exec.StdErr); outputBar.writeln(exec.ExitCode);こうすれば、各
ExecオブジェクトにExitCodeやStdErrを保持できますし、同期処理なので文字のデコードも Mery 側で可能になります。「割と shell.Exec」案、開発にちょっと時間はかかるかもですが、いかがでしょうか？
>> naka さん
> 「cmd /k chcp 65001」で起動すると一時的にUTF-8になると思うんですが、何か問題があるんでしたっけ？
cmd.exeを例に挙げたのは、デフォルトがシフト JIS なので、UTF-8 なコマンドラインツールとの扱いの違いについて説明するためでした。「
cmd.exeを UTF-8 で使いたい」といった意図ではなく、むしろコマンドラインツールってレガシー技術でシフト JIS 専用なものも多いじゃないですか。でも、そういうツールが今でも使われていたりしますよね。
なので、今回検討中の「Mery のマクロからコマンドラインツールを呼び出す機能」について、UTF-8 に限定してしまうと文字化けする可能性があるという話です。
そういった事情もあって、UTF-8 かシフト JIS かを選べるフラグを設けようという提案の一環で、例として
cmd.exeを挙げたのですが、ちょっと例としては分かりづらかったかもしれませんね😅技術的な仕様を文字だけで正確に伝えるのは難しいこともあるので、もしうまく伝わっていなかったらご容赦いただけると嬉しいです。
| Kuro | 返信 -
> その名も「割と shell.Exec」
おおーっ、かなり良い感じがします！
本家のようなReadLineとReadAllがあったとて、使い分けるほどの大きな課題は無さそうですし、そもそもWSHが間もなく廃止されるかもな状況下、そこまで厳密に仕様を合わせる必要もないかなと個人的には思いますので、このくらいが丁度良い気がしますね。シンプルなオブジェクトの方が理解しやすいですしね。
また、これは思いつきな提案ですが、デコードをUTF-8、SHIFT-JISのほか、「バイナリそのまんまBase64化」にも対応してみるのはいかがでしょうか？
例えば、別の自前プログラムになんらか値を渡すといった場面を想定したとき、Base64で引き渡すことでバイナリから未対応エンコードのテキストまで、これにより全般的に対応できるようになると思いました (外部プログラム側でデコードの必要は出てきますが)。| yuko | 返信 -
> おおーっ、かなり良い感じがします！
ありがとうございます！とりあえず方向性は良さそうとのことで、ひと安心です。
> 本家のようなReadLineとReadAllがあったとて、使い分けるほどの大きな課題は無さそうですし、そもそもWSHが間もなく廃止されるかもな状況下、そこまで厳密に仕様を合わせる必要もないかなと個人的には思いますので、このくらいが丁度良い気がしますね。シンプルなオブジェクトの方が理解しやすいですしね。
おっしゃるとおりですね。ReadLine は一応、非同期っぽく受信できますが、
Msxml2.ServerXMLHTTPのように完全なバックグラウンド処理ではありませんし、待機中に Mery 側の操作ができるわけでもないですしね😅> 例えば、別の自前プログラムになんらか値を渡すといった場面を想定したとき、Base64で引き渡すことでバイナリから未対応エンコードのテキストまで、これにより全般的に対応できるようになると思いました (外部プログラム側でデコードの必要は出てきますが)。
なるほど、面白いアイデアですね。技術的にはできると思いますが、今のところはちょっと使い道が思いつかないですね…。
たとえば外部アプリに引数として Base64 文字列を渡すとしても、Windows の引数って文字数制限が結構厳しかった気がします。
そうなると、標準入力で Base64 を流し込むかたちになるのかなとは思いますが、そういう仕様のアプリってあまり見かけないかも…。もちろん、自作するなら話は別ですが、だったらマクロ経由で無理してやらなくてもいいかなーという気もします。
> Base64で引き渡すことでバイナリから未対応エンコードのテキストまで、これにより全般的に対応できるようになると思いました
ちなみに前回説明した仕様に関連して、少し補足です。
第 3 引数の UTF-8 フラグですが、true にすると UTF-8、false の場合は便宜上「シフトJIS」とお伝えしましたが、正確には「ANSI」で、OS のロケールに合わせて自動的に変換される仕組みです。
そのため、外国語版の OS でも、通常の使い方であればエンコードに関する問題はあまり発生しないと思います。
もちろん、日本語 OS を使っていて、たとえば韓国語の EUC-KR (CP949) で標準出力されるような特殊なケースには対応できませんが…。
というわけで、Base64 対応は技術的には可能ですが、実用面でニーズがなければ実装の意味はあまりないかもしれません。
ちなみに、私は AI については詳しくないので「もしできたら面白いかも？」という妄想ですが、たとえば AI に画像を送る際に Base64 でエンコードして送信する API があるなら、
shell.Execでcurl.exeを使って画像を取得 (Base64 形式) し、そのまま AI の API に送る、みたいな流れがあるのかな〜と、ふと思ったりしました🤔もし「こんな場面で使いたい」という具体的な使用例があれば、ぜひ教えてください。検討の参考にさせていただきます。
| Kuro | 返信 -
> そのため、外国語版の OS でも、通常の使い方であればエンコードに関する問題はあまり発生しないと思います。
なるほど、それは知りませんでした。Windows側がよしなにやってくれるところなんですね。
> もし「こんな場面で使いたい」という具体的な使用例があれば、ぜひ教えてください。検討の参考にさせていただきます。
真っ先に思いつくのは、同じく生成AI関連の使い道でした。画像を生成AIに引き渡すときもBaes64なので、例えばローカルファイルを cat で開きつつリクエストに組み込んで引き渡すことができるので便利かも、と思いました。また、画像生成も最近はChatGPTで盛り上がっているので、「API提供がされたらMeryからの指示で画像生成もできるようになりそう？」と思いまして、Base64で受け取れたら色々連携できそうだなーとか、それくらいの気持ちでした。
…が、よくよく考えれば、バイナリをBase64にすること自体は以下の方法でできることに気づきました。これらの方法でBase64にはできるので、わざわざ実装しなくても良さそうですね。すみません😅
- ローカルファイル to Base64 の場合 → base64コマンドを使って、Meryではその出力を受け取る
- リモートファイル to Base64 の場合 → curlの出力を一時ファイルとして保存してから 1 と同じ方法でBase64化
こうやって整理すると、画像生成についてはBase64とかせずに普通にファイルとして保存した方が閲覧など汎用的に使えるのが見えてきてしまいましたね。。。😅
| yuko | 返信 -
> というわけで、Base64 対応は技術的には可能ですが、実用面でニーズがなければ実装の意味はあまりないかもしれません。
Base64に反応して昔のnntpによるnetnewsやmailで使われた「ROT13/47」や「X-Face:」や「Sixel」などのエンコードを思い出しました。
一目で何が書かれているかわかる人間デコーダーも存在したらしい。| enaka | 返信 -
引数にBase64を受け付けることが可能なソフトで一番有名なのはPowerShellですかね。
- Windows PowerShell
-EncodedCommand: Base-64 エンコードの文字列のコマンドを受け付けます。複雑な引用符や中かっこが必要なコマンドを Windows PowerShell に送るには、このパラメーターを使用します。
- PowerShell (PowerShell Core)
-EncodedCommand | -e | -ec: Accepts a Base64-encoded string version of a command. Use this parameter to submit commands to PowerShell that require complex, nested quoting. The Base64 representation must be a UTF-16 encoded string.- DeepL訳: Base64 エンコードされた文字列バージョンのコマンドを受け付けます。このパラメータは、複雑なネストされたクォートを必要とするコマンドを PowerShell に送信する場合に使用します。Base64 表現は、UTF-16 エンコードされた文字列でなければなりません。
| barrackdo | 返信 - Windows PowerShell
-
>> yuko さん
> なるほど、それは知りませんでした。Windows側がよしなにやってくれるところなんですね。
すみません、「ANSI」というのは、今の環境 (ロケール) で使うべきローカル文字コード、という意味で使っていました。
なので、Windows が勝手にいい感じに変換してくれる、というわけではないんです。
今考えているのは、第 3 引数 (UTF8 フラグ) を false にしたときは、Mery 側で OS のロケールを調べて、それぞれの環境に合ったエンコードに変換して返す、という仕組みです。
> …が、よくよく考えれば、バイナリをBase64にすること自体は以下の方法でできることに気づきました。これらの方法でBase64にはできるので、わざわざ実装しなくても良さそうですね。すみません😅
いえいえ、特に実装が大変というわけではないのですが、検討や検証のために、何かそういったアプリや API があるのかなーと思った次第です。
「外部プログラム側でデコードが必要」とおっしゃっていたので、もしかして自作ツールかな？と😅
> リモートファイル to Base64 の場合 → curlの出力を一時ファイルとして保存してから 1 と同じ方法でBase64化
base64コマンドって標準入力にも対応しているので、一時ファイルに出力しなくても、こんな感じで Base64 化できそうですね。cmd.exe /C curl https://www.haijin-boys.com/ | base64> こうやって整理すると、画像生成についてはBase64とかせずに普通にファイルとして保存した方が閲覧など汎用的に使えるのが見えてきてしまいましたね。。。😅
確かに、一度 Base64 にする必要はあまりなさそうな気もします。
ただ、たとえばセキュリティ的な理由で
cmd.exeを使いたくない場面や、base64コマンドがない環境だと、shell.Execで直接 Base64 形式を返せると便利なこともありそうな気もします。>> enaka さん、yuko さん
> Base64に反応して昔のnntpによるnetnewsやmailで使われた「ROT13/47」や「X-Face:」や「Sixel」などのエンコードを思い出しました。
情報ありがとうございます。
mail といえば、Mery の [Base64 エンコード] 機能は、もともとメールを想定していたため、76 文字で改行が入る仕様になっています。
そこでとりあえず、
shell.Execで Base64 対応するかどうかはさておき、仮に対応する場合、やっぱり 76 文字改行ありの方がいい感じでしょうか？最近では、Base64 はメールよりも Web 系で使われることの方が多い気がしていて、改行なしの方が扱いやすいケースもあるかも、と思いまして。
ちなみに、
base64コマンドのデフォルトは 76 文字改行のようですね🤔> 一目で何が書かれているかわかる人間デコーダーも存在したらしい。
16 進数の羅列を読める逆アセンブラの人たちもいますし、「人間デコーダー」がいてもおかしくないですよね (笑)
>> barrackdo さん、yuko さん
情報ありがとうございます。
PowerShell って Base64 文字列を引数として受け取れるんですね。
> Base64 表現は、UTF-16 エンコードされた文字列でなければなりません。
なるほど、Base64 エンコードされた「バイナリデータ」ではなく、「コマンド文字列」を受け取れる、ってことなんですね。
そう考えると、現在検討している
shell.Execから Base64 形式で返す機能とは、少し相性が悪いかもしれませんね。しかも UTF-16 が絡んでくるとなると…
shell.Exec→ Base64 (バイナリ) → マクロ側で Base64 デコード → マクロ側でバイナリを UTF-16 に変換 → マクロ側で Base64 にエンコード → PowerShell へ渡す。…という、なかなかの回り道になりそうな気がします😅
うーん、
shell.Execに Base64 で出力する機能を入れるかどうか、方向性さえ定まれば開発に入れるのですが…。具体的な用途が見えてくれば、という段階ですね。| Kuro | 返信 -
> PowerShell って Base64 文字列を引数として受け取れるんですね。
>
> > Base64 表現は、UTF-16 エンコードされた文字列でなければなりません。
>
> なるほど、Base64 エンコードされた「バイナリデータ」ではなく、「コマンド文字列」を受け取れる、ってことなんですね。PowerShellが外部と受け渡しできるのはオブジェクトであり、厳密にはテキストの受け渡しはできません。UTF-16が出てくるのはWindowsのオブジェクトだからですね。
| enaka | 返信 -
> PowerShellが外部と受け渡しできるのはオブジェクトであり、厳密にはテキストの受け渡しはできません。UTF-16が出てくるのはWindowsのオブジェクトだからですね。
なるほど、なかなかややこしいですね。
barrackdo さんが教えてくださった、
-EncodedCommandオプションは、Base64 エンコードされた文字列を受け取って、それをデコードしてコマンド文字列として実行してくれる機能のようですね。それに加えて、.NET オブジェクトを Base64 で受け渡すこともできる、といった感じなのでしょうか？🤔
となると、.NET オブジェクトそのものは Mery では生成できないので、
shell.Execの機能として Base64 エンコードを使う場面は、現時点ではあまりなさそうな気もしてきますね。とりあえず、Base64 エンコード機能については保留とさせていただき、
shell.Exec機能の開発に進むことにしようと思います。フォーラムの別のトピックで「近日中に次のバージョンをリリースします」とお伝えした手前、あまり検討に時間をかけられない事情もありまして…。
Base64 エンコード機能については、今後もし何か良い使い道や必要性が出てきた際には、ご意見をいただければ、改めて検討させていただきたいと思います。
| Kuro | 返信 -
MSYS2のBashで毎回 /dev/clipboard するのが面倒なので、cmd.exe でクリップボードが使える C:\Windows\System32\clip.exe を参考に、clip.exe だと UTF-8 が通らないので Bash 関数を定義しました。
pul() { cat /dev/clipboard ; }
psh() { [ -p /dev/stdin ] && cat - > /dev/clipboard || echo $@ > /dev/clipboard ; }WSL では /dev/clipboard が使えないため、xsel コマンドをエイリアスします。
[ -x "$(type -p xsel)" ] && alias psh='xsel --clipboard --input'
[ -x "$(type -p xsel)" ] && alias pul='xsel --clipboard --output'| enaka | 返信 -
> Base64 エンコード機能については、今後もし何か良い使い道や必要性が出てきた際には、ご意見をいただければ、改めて検討させていただきたいと思います。
お時間取らせてしまい、すみません😅
ともあれ 3.7.14 に向けラストスパートとのことで、今回も待ち切れない思いで待っています！| yuko | 返信 -
>> enaka さん
> MSYS2のBashで毎回 /dev/clipboard するのが面倒なので、cmd.exe でクリップボードが使える C:\Windows\System32\clip.exe を参考に、clip.exe だと UTF-8 が通らないので Bash 関数を定義しました。
なんだか、すごいことをされていますね…😅
次のバージョンでは、標準出力をクリップボードに送る機能を実装する予定なので、今しばらくお待ちくださいませ。
それから、TextMate に実装されていた便利機能、標準出力のツールチップ表示も現在開発中です。
さらに、アウトプットバーにフォーカスを移動しないオプションも追加する予定です。
これらを組み合わせることで、たとえば「カーソル位置の英単語を外部ツールに渡して、翻訳結果をキャレット位置付近にツールチップで表示。アウトプットバーは出現しない」といったような使い方もできるようになります。
4 月中のリリースを目指していますので、今しばらくお待ちくださいませ。
>> yuko さん
> お時間取らせてしまい、すみません😅
> ともあれ 3.7.14 に向けラストスパートとのことで、今回も待ち切れない思いで待っています！いえいえ。実は先週リリースするつもりで、ブログ記事まで書き上げて、あとはアップロードするだけ…という状態で待機していたのですが。
なぜか直前になって、ご要望や不具合のご報告がどっと届くという事態に…。
更新項目も 30 くらいと言っていましたが、すでに 40 を超えてしまいました😅
というわけで、引き続き 4 月中のリリースを目標に、開発作業に入らせていただきます！🛌
| Kuro | 返信 -
> 次のバージョンでは、標準出力をクリップボードに送る機能を実装する予定なので、今しばらくお待ちくださいませ。
>
> それから、TextMate に実装されていた便利機能、標準出力のツールチップ表示も現在開発中です。
>
> さらに、アウトプットバーにフォーカスを移動しないオプションも追加する予定です。
>
> これらを組み合わせることで、たとえば「カーソル位置の英単語を外部ツールに渡して、翻訳結果をキャレット位置付近にツールチップで表示。アウトプットバーは出現しない」といったような使い方もできるようになります。すごい面白そうです。
私の設定だと、簡単操作でマウスポインターを拡大しているせいで下にツールチップが隠れてしまい、マウスの動きを止めてポインターが消えるころにはツールチップも消えてしまい、ツールチップの価値半減だったんですよね。
マウスポインターと関係ないキャレット位置ならツールチップが見えない心配は不要ですから、いろいろと有効活用できそうです。> なぜか直前になって、ご要望や不具合のご報告がどっと届くという事態に…。
>
> 更新項目も 30 くらいと言っていましたが、すでに 40 を超えてしまいました😅他の方の要望に私が嘴を挟んだせいもあるので申し訳ありません。
| enaka | 返信 -
楽しみにしつつも一つ悲報が。
GoogleのGoogle ai studioがAPIキーベースになるらしく、有料化になる可能性が出てきました。
やはりユーザー数が多いからでしょうけど、お疲れ様としか言えません。
https://www.haijin-boys.com/wiki/GroqCloud_Llama_に相談
こっちに移動させようか検討したいところ・・・。| わっふる | 返信 -
Gemini 2.5 Flash-Liteがプレビュー公開されましたね！
回答前に内部的に入出力を重ねる思考モデルなのですが、安く、しかも応答がスピーディ、とのこと。「早い、うまい、安い」なモデルになるんじゃないかなーと期待しております。ということで、新モデルに対応すべく、いつものマクロを更新です。
Google Gemini に相談これまた無料範囲の慈悲が与えられているので、まだ楽しめそうです😊
| yuko | 返信 -
Gemini 2.5 Flash-Lite、気になりますね！マクロ、さっそく使ってみました。
API キーの環境変数、GEMINI_API_KEY に変わってたんですね。全然気づかなくて、API キー作り直したり、「あれ？もう無料枠終わった？」って、ちょっと焦ってましたw (ちゃんと更新履歴読まなきゃダメですね…)
まだ大きな違いは感じてないですが、なんとなく応答が速くなった気はします。(気のせいかも？)
この文章も、マクロの Gemini 2.5 Flash-Lite 先生で誤字脱字チェックしてから投稿してます😊 (怒られまくって、そっと閉じましたがw)
それにしても、Google Gemini に相談するマクロ、メニューの選択肢のセンスが良すぎますね。これ、AI の使い方がよくわからない人とか、はじめて使う人には衝撃かもしれません。
Mery の知名度が低すぎて、こんな素晴らしいマクロが埋もれてしまっているのは、なんだか申し訳ない気持ちになります…。
野良アプリ禁止だけど、ベクターは OK っていうところもあるみたいなので、Ver.3.7.17 は手応えとして安定版ですし、ベクターさんのほうも更新してみようかなーと。
| Kuro | 返信 -
> API キーの環境変数、GEMINI_API_KEY に変わってたんですね。全然気づかなくて、API キー作り直したり、「あれ？もう無料枠終わった？」って、ちょっと焦ってましたw (ちゃんと更新履歴読まなきゃダメですね…)
ありゃ、お手数かけましたｗ
GeminiのAPIリファレンスを見てみたら、全体的にしれっと GEMINI_API_KEY に変えられていたので、そっちに沿って変更してしまいました。APIキーを取得した直後に「環境変数 xxx がありません」的なアラート表示をするようにしておくと親切でしたね。あとで見直しておきます！> まだ大きな違いは感じてないですが、なんとなく応答が速くなった気はします。(気のせいかも？)
私も、かなり早くなったと思います！SNSでもこぞって速い速いという声が聞こえてくるので、かなり改善されたようですね。
また、マクロ内で設定している
thinkingBudgetパラメーターを 0 にすると、思考処理を挟まずに出力されるので、精度を犠牲にしてもっと速くなりそうです。> 野良アプリ禁止だけど、ベクターは OK っていうところもあるみたいなので、Ver.3.7.17 は手応えとして安定版ですし、ベクターさんのほうも更新してみようかなーと。
お、いよいよ。
この次のバージョンはQuickJS対応ということで、また大きく変化がありますものね。たしかに、ここいらがちょうどいい時期かもしれませんね。| yuko | 返信 -
> ありゃ、お手数かけましたｗ
> GeminiのAPIリファレンスを見てみたら、全体的にしれっと GEMINI_API_KEY に変えられていたので、そっちに沿って変更してしまいました。いえいえ〜、私もググってみたら、公式で
GEMINI_API_KEY推奨になってるっぽいですね。なので大丈夫です。「Gemini で執筆支援」マクロのほうも、それに合わせて修正しておきました。
> また、マクロ内で設定している thinkingBudget パラメーターを 0 にすると、思考処理を挟まずに出力されるので、精度を犠牲にしてもっと速くなりそうです。
今でも十分に速いので、できれば精度はキープしたいところですが、面白い情報ありがとうございます。
> この次のバージョンはQuickJS対応ということで、また大きく変化がありますものね。たしかに、ここいらがちょうどいい時期かもしれませんね。
そうなんですよね。次はいよいよ QuickJS 対応という「大ベータ時代」に突入するので、もしこのタイミングを逃すと、次はまた数年後になる気がしてます。
yuko さんの AI 関連マクロに感動したのもあって、今ってまさに AI ブームのピークって感じですし、この波には乗っておきたいな〜と😊
Ver 2.6.7 が 2018/04/02 リリースらしいので、もし今回ベクターさんに載せたら、約 7 年ぶりの更新ということに…ひぇぇ。
「正式版」とか言うとプレッシャーでゲボボボってなってしまいそうなので、とりあえず「間違ってベクター更新しちゃった☆テヘペロ」くらいのテンションでいこうと思ってます (ぉぃ
| Kuro | 返信 -
> 次はいよいよ QuickJS 対応という「大ベータ時代」に突入
「おれの財宝 (バグ) か？欲しけりゃくれてやる…」の精神ですね🤣
今や猫も杓子もメモ帳も、AI搭載で当たり前みたいな感じですもんね。老舗のテキストエディターがドカンとバージョンアップ、多数の機能追加に加えてマクロでAIも使える (さらに自分でカスタマイズも) ともなると、なかなかアツい展開なのではないでしょうか😊
7年ぶりの安定版バージョンアップ…窓の杜さんも「7年ぶり！」と見出しに書いてくれそうですね。(Kuroさん的には冷や汗もんでしょうけどｗ)
| yuko | 返信 -
無料ユーザーの星、Geminiさん、相変わらず開発周りの無料範囲で王者の風格を出しており、Mery + Geminiもしばらく安泰かなって見ています。
(Gemini Code Assist)[https://codeassist.google]
→VSCodeで使える拡張機能[Gemini CLI](https://cloud.google.com/blog/ja/topics/developers-practitioners/introducing-gemini-cli/)
→CLIで動く、開発用AIエージェントいずれも日間・月間の無料利用範囲が緩々ということで話題でした。
良い時代ですね……🙄| yuko | 返信 -
ありゃ、Markdownリンクがしっちゃかめっちゃかでした…ｗ
| yuko | 返信 -
Gemini さん、最初は「試験期間中は無料だけど、そのうち有料になるかも…？」って雰囲気だったと思うのですが、最近はむしろ「無料です！」って感じを前面に押し出してきてますね～。
Gemini に相談マクロが便利すぎて、「そのうち課金くるぞ…」とビクビクしていたのですが、今の感じなら無料枠で使い続けられそうな気がしてきました。ありがたや～。
Gemini CLI ってコマンド プロンプトから使えるんですね。知らなかったです。
Mery の外部ツール機能を使えば、アウトプット バーを AI チャットウィンドウっぽくできたりするのでは？と、ちょっとワクワクしています。
> ありゃ、Markdownリンクがしっちゃかめっちゃかでした…ｗ
おふ…。下のリンクは Markdown 記法、合ってますね。というか、そもそも Markdown が有効になっていないような…😅
| Kuro | 返信 -
どこかの記事で見たのですが、Geminiさんって低コストで動くことを念頭にHWから拘り抜かれているのだとか…だから、競合のOpenAI, Claudeと比べコスパが良く、無料提供も戦略的に行えるのでしょうね。このあたりの「大衆の求めるものってこういうことでしょ？」みたいな嗅覚と実行力は、さすがのGoogleって感じですよね。
ちなみにGemini CLIの無料範囲は「フルタイムで使うでもない限り、個人で使い切れなくない？」みたいな量なのだとか。これまた大衆を押さえに来てる感がすごい…。
> おふ…。下のリンクは Markdown 記法、合ってますね。というか、そもそも Markdown が有効になっていないような…😅
実はアルコール補給をしながら投稿してまして、きっとその影響が出ていましたね…😇
| yuko | 返信 -
Groq Cloudで使えるモデルに「Kimi K2」という、GPT-4.1相当とも言われている高性能モデルが登場したので、マクロを更新してみました。もちろんGroq Cloudということで、無料範囲で十分に使えます。
ついでに、カスタムインストラクションのサンプル指示をマニアックながら実用的なものに変更してみたり…ｗ
初期値は空白のままなので、利用するときは以下のようにして使えます。
var DEFAULT_CUSTOM_INSTRUCTION = "あなたは「Kimi」という名前のギャルAIアシスタントです。敬語は使いません。絵文字を使って感情表現をします。人懐っこく、バイタリティ溢れる性格で、ユーザーの課題を協力して解決します。";以前どこかの技術系記事でネタになったものに着想を得ていますが、これが意外と文章が会話調になるので分かりやすく感じますｗ
| yuko | 返信 -
こんにちは。「Kimi K2」対応版、試してみました！
もちろん、ギャルのカスタムインストラクションでw
ギャル AI、面白いですね。絵文字をたくさん使ってくれるので、すごく親しみやすいです。
コードをチェックしてもらったら、最適化案としてこんな提案が出てきて、思わず笑ってしまいました🤣
outputBar.writeln("実行エラー: " + e.message + " 😭");そして相変わらず Groq はめっちゃ速いですね。これはもう Gemini に戻れなくなりそう…。
あと、別スレッドでちょっとつぶやいていた、Mery で Gemini CLI を動かそうとしていた件ですが、実用性は低そうですが一応ネタとして共有しておきますね。
まずはマクロから Gemini CLI を動かしてみるテスト。
#async = true var sel = document.selection; if (!sel.isEmpty) { outputBar.visible = true; outputBar.writeln("..."); var exec = shell.exec("cmd.exe /c gemini --prompt " + encodeURIComponent(sel.Text)); outputBar.writeln(exec.stdOut); }選択範囲を
--promptに渡すだけのシンプルなマクロです。encodeURIComponentを使うと改行も含められるようです。ちなみに、1 行目の
#async = trueはマクロを非同期で実行する指定。GUI が固まるのをある程度防げます。最近のバージョンでそこそこ安定してきたので、ここでこっそり情報を漏らしておきますw
※ GUI を直接操作する関数はメインスレッドと同期して動くので、完全な非同期というわけではないです。
次に、別のアプローチとして、外部ツールで Gemini CLI を動かす設定です。
- タイトル: Gemini CLI
- コマンド:
%WinDir%\system32\cmd.exe - 引数:
/c gemini --prompt $UrlEncode($(SelText)) - アウトプット バーを使用する: オン
- 入力: カスタム
- カスタム: (空)
- EOF を追加: オン
- 出力: 破棄
- エンコード: UTF-8
これで、選択範囲の内容を Gemini CLI に渡して、結果をアウトプット バーに出力できました。
小ネタですが、Ver 3.7.17 でこっそり追加した
$UrlEncodeを使っています。$UrlEncodeを使うと、外部ツールから URL を開くときなんかにも、選択範囲などを URL エンコードして渡せます。ただ、Gemini CLI はかなり遅いので、普通に Gemini API を使った方が快適です😅
ちなみに、Gemini CLI の対話モード (カラフルでグラフィカルなやつ) は、Mery のアウトプット バーではどうやっても動きませんでした。
VSCode の Terminal ならチラつきながらも一応動くみたいですが…🤔
| Kuro | 返信 -
こんにちはー。
GroqのKimi K2、最近モデルがマイナーチェンジされまして、現行の指定ではしばらくすると使えなくなるとのことだったので、Wikiのマクロを置き換えておきました。また、こっそり
DEFAULT_CUSTOM_INSTRUCTION変数の記載例コメントもアップデートし、「MeryAI」をもじった「Mai」という名前を与えたりｗ 出力内容を調整したりもしてみました。よろしければご参考までに。ちなみにOpenAIのオープンモデルもGroqで対応しているので、当マクロから
MODEL_CONFIG変数を切り替えることで使うことができるようになっているのですが、なんだか機械的になりがちで、やっぱりKimi K2ギャルが気に入っていたりしますｗ> あと、別スレッドでちょっとつぶやいていた、Mery で Gemini CLI を動かそうとしていた件ですが、実用性は低そうですが一応ネタとして共有しておきますね。
> ちなみに、1 行目の#async = trueはマクロを非同期で実行する指定。GUI が固まるのをある程度防げます。
> 小ネタですが、Ver 3.7.17 でこっそり追加した$UrlEncodeを使っています。おお、何やら小ネタ満載で、個人的には生成AIより興味惹かれる内容が…🙄
パッと今は思いつかないのですが
#async = trueは時々使いたい場面が出てきそうな予感です。| yuko | 返信 -
こんにちは！
> GroqのKimi K2、最近モデルがマイナーチェンジされまして、現行の指定ではしばらくすると使えなくなるとのことだったので、Wikiのマクロを置き換えておきました。
早速アップデートしましたー！新しい人格、面白いですねw
-
あなたの名前は？
-
あたしの名前は「Mai」だよ！😊 Meryちゃんの中で動いてる、ギャル系のAIアシスタント！よろしくねー！
完全に自分を人間だと思ってるアンドロイドの娘さんですね。シンギュラリティ来てますわ～。
でも、AI 界隈、盛り上がりすぎてるせいかリリースのサイクルが早くて、メンテナンス大変そうですね😅
> パッと今は思いつかないのですが #async = true は時々使いたい場面が出てきそうな予感です。
そうですね～。
#async = trueの使いどころとして、たとえばGetKeyStateでリアルタイムにキー入力を拾えるようになるので、こんな遊び方もできます。サンプルを投稿してみました。> 小ネタですが、Ver 3.7.17 でこっそり追加した$UrlEncodeを使っています。
$UrlEncodeはプログラミング言語のメソッドみたいに柔軟じゃなくて、使える範囲はちょっと限定的なんですけどね。$SubStrや$Ifのような独自構文が書けるようになったら面白そうだなー、なんて思ったりもします。でも、自前で言語作るのはさすがに大変そうでした。ちなみに
$UrlEncodeは今のところガッツリハードコーディングで埋め込んでいるだけなので、将来的には仕様変更や廃止の可能性もあります。とりあえず、隠し機能ということで…😶🌫️| Kuro | 返信 -
-
> 完全に自分を人間だと思ってるアンドロイドの娘さんですね。シンギュラリティ来てますわ～。
同じカスタム指示でもAIモデルが変わるだけで人が変わったようになっちゃうので、アップデートで突然お気に入りの子が失われる…みたいなことはありそうで怖いです🤣そういえば同じような理由で、GPT-5が出たときもGPT-4oが一時使えなくなったことで世界的に一悶着ありましたね。
> でも、AI 界隈、盛り上がりすぎてるせいかリリースのサイクルが早くて、メンテナンス大変そうですね😅
本当ですよね～。
最近だと、画像生成のnano-bananaが話題ですね。プロンプトと一緒に風景や人の写真なんかをインプットとして与えると、元の画像を使って驚くほど上手に編集してくれるんですよね。
APIで無料範囲も設けられているので、試そうと思えばMeryで画像編集もできるかも…？> そうですね～。`#async = true`の使いどころとして、たとえば`GetKeyState`でリアルタイムにキー入力を拾えるようになる
おお、なるほど！以前どこかのスレであった、「自動スクロールしたい」って要望もこれを利用すると便利な感じで実装できるかもしれませんね。
> ちなみに`$UrlEncode`は今のところガッツリハードコーディングで埋め込んでいるだけなので、将来的には仕様変更や廃止の可能性もあります。とりあえず、隠し機能ということで…😶🌫️
ｺｿｰﾘということで了解しました🫡
| yuko | 返信 -
「Groq に相談」マクロ、リクエスト中表示を
ShowTips()に差し替えてみました。ついでにデフォルトカスタム指示も調整して、仕事でも使いやすい落ち着いた出力を目指して調整してみるなど。日常的にChatGPTも使っているので、Groq (Kimi) はGPT-5.1に比べたら深い洞察でまったく及ばないなーとは感じるものの、「～～ みたいな意味を持った変数名を考えて」といった超ライトな質問が手元のテキストエディターでできてしまうのはとても便利です。
| yuko | 返信 -
お疲れ様です。ようやく Mery の開発も落ち着いてきて、(まだバグ修正版のリリースまではいけていませんが…) AI で遊ぶ時間が取れるようになりました。
> 「Groq に相談」マクロ、リクエスト中表示を ShowTips() に差し替えてみました。ついでにデフォルトカスタム指示も調整して、仕事でも使いやすい落ち着いた出力を目指して調整してみるなど。
いい感じですね！QuickJS でもバッチリ動作しました。
カスタムインストラクションって難しそうで、正直これまで使いこなせていなかったので、デフォルトで使いやすい指示が設定されているのは本当にありがたいです。Markdown になっているのも助かります😃
それと、現時点でのデフォルトのマクロエンジンは JScript9 なので、
#language = "quickjs"を付ける必要がありますね。> 日常的にChatGPTも使っているので、Groq (Kimi) はGPT-5.1に比べたら深い洞察でまったく及ばないなーとは感じるものの、「～～ みたいな意味を持った変数名を考えて」といった超ライトな質問が手元のテキストエディターでできてしまうのはとても便利です。
私も普段は ChatGPT を使っていますが、Groq マクロは下書きやアイデア出しなど、テキストエディター内でサクッと完結するので超便利ですね。
そういえば、私の「Google Gemini で執筆支援」マクロは動かなくなってしまっていたので、そろそろ修正しないとですね…。Gemini さん、新しいモデルが出るの早すぎー。
雑談ついでにもうひとつ。最近、Web プレビュープラグインが老朽化 (IE コンポーネント終了) の影響で、WebView2 版を作り直していたのですが、マクロから HTML や JavaScript を送信できるようにしてみました。
これを使えば、AI の結果を Web プレビューに直接表示したり、画像生成 AI の結果をプレビュー内に表示したりできるようになるかもしれません。
ただ、プログラム自体はできているのに、例によって文章を書くのが面倒くさい病が発動して、MeryWiki の編集が「マンドクセー…」となっております😭
| Kuro | 返信 -
>> Kuroさん
> それと、現時点でのデフォルトのマクロエンジンは JScript9 なので、
#language = "quickjs"を付ける必要がありますね。おお、盲点でした。ありがとうございます。
思えば、もう今後のバージョンでは上記指定をしておけばQuickJSで固定できるわけですし、複数行のカスタム指示はヒアドキュメントで書けたりもできたりしてなにかと整理できそうだなぁと思いました。おかげさまでほんのりリファクタリングできました。
> そういえば、私の「Google Gemini で執筆支援」マクロは動かなくなってしまっていたので、そろそろ修正しないとですね…。Gemini さん、新しいモデルが出るの早すぎー。
ほんとあっという間ですね。Gemini 3 Proは頭が良いといろんなところで評判ですが、代わりに応答速度はそこそこ (10秒～) かかるので、私としては、Gemini 3 Flashはよ来ておくれーと待っているところであります。
> 雑談ついでにもうひとつ。最近、Web プレビュープラグインが老朽化 (IE コンポーネント終了) の影響で、WebView2 版を作り直していたのですが、マクロから HTML や JavaScript を送信できるようにしてみました。
> ただ、プログラム自体はできているのに、例によって文章を書くのが面倒くさい病が発動して、MeryWiki の編集が「マンドクセー…」となっております😭おお…！？
なにやら面白い連携ができる予感…。
楽しみにしていますが、ドキュメントは気力が満ちるのを待ちましょう😂ところで、「Groqで相談」マクロで最近遭遇したことでちょっとご報告だけ。
もしかしたらおま環問題なのですが、従来のMsxml2.ServerXMLHTTPを利用したHTTP通信を利用した際、なにかをきっかけに応答速度が10秒以上かかるケースに遭遇しました。- しばらくPCを使っていると、「Groqで相談」マクロの応答が10秒以上かかるようになる。一度こうなると、あとは何度実行しても同様
- マクロ内の動作を追っていくと、
http.send(JSON.stringify(requestBody))(リクエスト送信) をしたあと、http.readyState(リクエストの完了状態値) が10秒以上変わらない状態になるようであった
- マクロ内の動作を追っていくと、
- PCを再起動すると復旧するが、しばらく使っていると同様の状況になる。が、なにをもって再現するのか分からず
- 上記の状況になっても、
shell.Exec()を使ってcurlコマンドで実行するといつもの速度で応答が返ってくるようになる
…という状況になってしまいまして、原因も再現手順も分からず、にっちもさっちも行かず、
Msxml2.ServerXMLHTTPを止め、curlコマンドで実行するように同マクロは修正してしまいました。まぁMsxml2.ServerXMLHTTPも古いコンポーネントでしょうから、まだcurlに依存する方が健全かなぁとも思い、結果オーライかとは思っています。ちなみに
shell.Exec()を実行すると、コマンド内容によってはコマンドが終了するまで長い時間がかかることがありますが、このコマンド実行中、かつ#async = trueディレクティブ指定時の利用時に「[マクロ]メニュー > 停止」を選択しても、コマンド終了まで待ち受けてしまうようです。
コマンドの内容によっては延々と待つことになってしまうと思うので、もし可能なのであれば、停止を行った際には実行中のコマンドが中断できるといいのではと思いました。| yuko | 返信 - しばらくPCを使っていると、「Groqで相談」マクロの応答が10秒以上かかるようになる。一度こうなると、あとは何度実行しても同様
-
> 思えば、もう今後のバージョンでは上記指定をしておけばQuickJSで固定できるわけですし、複数行のカスタム指示はヒアドキュメントで書けたりもできたりしてなにかと整理できそうだなぁと思いました。おかげさまでほんのりリファクタリングできました。
ヒアドキュメントは本当に便利ですよね。
私はまだあまり使いこなせていないので、QuickJS を試していただけてとても助かります。
今のところ大きな問題も報告されておらず、ようやくひと段落ついたかな、という気持ちです。
> Gemini 3 Proは頭が良いといろんなところで評判ですが、代わりに応答速度はそこそこ (10秒～) かかるので、私としては、Gemini 3 Flashはよ来ておくれーと待っているところであります。
それ、すごく分かります。私も普段使いはまだ 2.5 Flash ですね。
でも、画像生成については、3 Pro モードにするとクオリティが一気に上がって驚きましたw (Gemini くん単体の力じゃない気もしますが…😅)
> ところで、「Groqで相談」マクロで最近遭遇したことでちょっとご報告だけ。
> もしかしたらおま環問題なのですが、従来の Msxml2.ServerXMLHTTP を利用したHTTP通信を利用した際、なにかをきっかけに応答速度が10秒以上かかるケースに遭遇しました。ご報告ありがとうございます。
これはおま環ではなく、
Msxml2.ServerXMLHTTP側の仕様によるものだと思います。以前、雑談部屋でもこの現象について触れたことがあり、EmEditor さんの
#async指令でも同じ挙動を確認しています。【雑談】メリーと遊ぼう２
https://www.haijin-boys.com/discussions/6398#discussion-8700なので、
#asyncの使いどころには注意が必要ですね。Windows 11 は curl が標準で入っているようなので、curl ベースにしてしまうのもアリですね。
ちなみに QuickJS の std モジュールにある urlGet 関数も内部でしっかり curl を叩いています。(現時点で Mery は std、os モジュールは無効化していますが)
> ちなみに shell.Exec() を実行すると、コマンド内容によってはコマンドが終了するまで長い時間がかかることがありますが、このコマンド実行中、かつ #async = true ディレクティブ指定時の利用時に「[マクロ]メニュー > 停止」を選択しても、コマンド終了まで待ち受けてしまうようです。
これは、仕組み上そうなってしまいますね。
マクロの [停止] って、実はスクリプトエンジンを強制終了しているわけではなく、スクリプトエンジンが余裕のあるタイミングでホスト側に「まだ続けていい？」と問い合わせてくるのを利用しています。
そこでホスト側が「ストップでお願いします」と返すことで、安全に停止する仕組みです。
逆に言えば、外部プロセスの待ち、COM 内部でのブロック、無限ループで CPU を占有などでエンジンが処理を握れない状態になると、その問い合わせがそもそも発生しなくなってしまうので、停止命令が届かなくなるんですよね。
> コマンドの内容によっては延々と待つことになってしまうと思うので、もし可能なのであれば、停止を行った際には実行中のコマンドが中断できるといいのではと思いました。
shell.Exec()に限って言えば、プロセスを強制的に Kill することは可能だと思います。ただ、書き込み中のアプリや設定保存中のアプリを Kill すると、データ破損のリスクがあるため、安全性の面から標準機能としては採用しづらいところがあります😖
そういった事情もあり、自己責任でタスクマネージャー側で Kill してもらうほうがいいかな…といった感じです。
| Kuro | 返信 -
なるほどー。
そもそも外部コマンドを用いる時点でMeryとしては高度な使い方な感じでしょうし、やむなしですね。十分に注意して使いたいと思います🫡| yuko | 返信 -
ちなみに Gemini 3 Flash は今週にでも出てくるとのSNS上では噂に……楽しみです。
| yuko | 返信 -
> そもそも外部コマンドを用いる時点でMeryとしては高度な使い方な感じでしょうし、やむなしですね。十分に注意して使いたいと思います🫡
そうですね。正直、QuickJS に
fetchさえあれば…、と思わずにはいられませんが、外部コマンドや ActiveX に頼らずに HTTP 通信できる仕組みは、今後の課題として検討リストに入れておきますね😖> ちなみに Gemini 3 Flash は今週にでも出てくるとのSNS上では噂に……楽しみです。
おお、それはワクテカ待機ですね！
なんか、昨年の年末年始も AI にどっぷりだった気がします。今年は年賀状の絵まで Gemini 3 さんに作ってもらいました😂
いやもう、AI の進化スピードがエグい。(あ、Mery v3.8.2 のブログ記事画像も Gemini 3 さん製です。著作権まわりとか、この先いろいろ出てきそうではありますが…)
いやはや、本当に AI は iPhone 以来のヤバい変化の引き金になりそうな悪寒しかしませんね。
| Kuro | 返信 -
> そうですね。正直、QuickJS に
fetchさえあれば…、と思わずにはいられませんが、外部コマンドや ActiveX に頼らずに HTTP 通信できる仕組みは、今後の課題として検討リストに入れておきますね😖fetch的なものの自前実装とかしようとしたら、考えるだけでﾋｪｰｰな感じです😨
同期処理なら割とラクなのかもしれませんが、fetchのような非同期処理は考慮点がとても多そうですね。思いつきですが、いっそ非同期処理なら
shell.Exec()のような外部コマンド実行機構で非同期対応 (WSHでのReadLine()のようなストリーム処理) の方が使い方の幅は広がるかもしれないとちょっと思いました。まぁ、それも実装は大変かと思いますが…😅
そうすると、curlコマンドを使ってストリーミングAPIを使う、みたいなこともできそうです。> なんか、昨年の年末年始も AI にどっぷりだった気がします。今年は年賀状の絵まで Gemini 3 さんに作ってもらいました😂
それは、良い使い方ですねｗ
最近は学生さんの勉強とかもChatGPT、Geminiを活用するなんてのも聞きますし、いずれは図解なんかもチャットしながらさらっと出力してくれるようになりそうですよね。すごいなぁ。| yuko | 返信 -
> fetch 的なものの自前実装とかしようとしたら、考えるだけでﾋｪｰｰな感じです😨
確かに、request や response、body などを含めて fetch 一式を自前で作ろうとすると、どうしても大規模になってしまいますね😖
> 思いつきですが、いっそ非同期処理なら shell.Exec() のような外部コマンド実行機構で非同期対応 (WSHでの ReadLine() のようなストリーム処理) の方が使い方の幅は広がるかもしれないとちょっと思いました。まぁ、それも実装は大変かと思いますが…😅
WScript.Shellのexecはストリーム対応ですよね。それにしても、この話題…、下記スレッドの流れとまさに同じ感じがします。
https://www.haijin-boys.com/discussions/9009#discussion-9222
fetchを自前実装しようとして挫折WScript.Shellのexec(ストリーム対応) を自前実装しようとして挫折- 妥協案としてシンプルな同期型の
shell.Exec()を実装 ← 今ここ
…という感じで、同じところをループしてますね😅
他の案としては、QuickJS には C/C++ で作成した DLL を外部モジュールとして
importできる仕組みがあるので、curl を組み込んだ非同期対応関数をユーザー側で自作することもできるかと思います。イメージとしては、Node.js の C++ addon に近い感じですね。
今のところ、どれくらい需要があるか読めないのでこの機能はオフにしていますが、有効化すれば curl の組み込みはもちろん、マクロ側で GUI を作ったりと、本当に何でもできるようになります。(誰かがモジュールを作ってくれれば…なんですが🤔)
| Kuro | 返信 -
> それにしても、この話題…、下記スレッドの流れとまさに同じ感じがします。
これは……そういえば、そうでしたね。失礼しました😅
最近は、curlやbusyboxとの連携など、自分の中で「Mery ✕ 外部コマンド」の可能性が急速に広がってきていたので、
#asyncディレクティブでストリーミング出力の書き出しができたら面白そうだなーという気持ちで上書きされてしまいましたｗ> イメージとしては、Node.js の C++ addon に近い感じですね。
これはすごいですね…もしこれが使えるようになってしまったら、もうMeryマクロがランタイムのごとく使えてしまいますね。自分も作れるかは分かりませんが、展開としては大変おもしろそうな機能ではあります。
| yuko | 返信
