Zenn
Open199

2025-2

podhmopodhmo

2025年版 2

はじまり

  • 記事の目的

この記事の目的

zennのscrapsはかなり便利なのだけれど、不要なscrapを立ち上げてすぐに辞めるみたいな作業をしがち、そんなわけで一覧部分にはタイトルだけに近いようなメモの残骸が並んでSN比が悪くなる。
（これはgithub issuesも同様の問題）

github issuesより良いところは

  • リンクを貼るとcard UIで良い感じにOGP的な情報を展開して表示してくれる
  • github discussionsと同様に複数の枝を持たせて各枝毎にコメントを書くことができる

そしてChangeLogメモのように一箇所にまとめるという意味で一箇所に集約してみると良いのでは？という感じになった。というわけで2024年版をここに書くようにする。

ついでに、作ったscrapsのメモをここに載せていくようにしてあげれば大きな意味でのmeta scrapsに使える気もした。

podhmopodhmo

2025-04-04

  • 個人的なllmとの付き合い方
  • 省エネ個人用apiサーバー
  • 最近スマホでやってること
podhmopodhmo

個人的なllmとの付き合い方のまとめ

LLMにおいても以下の内容は真ですか？

  • 入力から次に来るであろう文章を予測してるだけ
  • 内挿は得意でも外挿は苦手
  • 結局のところ近傍探索（否定形は苦手だし存在しなくても最も近しいものを選ぶだけ）

色々試してみたところこれくらいの質問だとgrokよりもgemini 2.5 proの方が賢そうだった。

https://x.com/i/grok/share/Ej4bDFb3WFmikVSlL5f2h6JLN

grokはreduceのことを気にしてくれなかったがgeminiは気にしてくれた。なので会話が回答のサブセットになった。なので対話をコピペで済ませられなかった

https://aistudio.google.com/app/prompts?state={"ids":["1wXRaI7WHeG7SsfueanOiz4vjA2QauYOr"],"action":"open","userId":"108405443477417806091","resourceKeys":{}}&usp=sharing

podhmopodhmo

cloud run

https://aistudio.google.com/app/prompts?state={"ids":["100Qq_viPg4pzdzdYJo5UdI88f43_-cFp"],"action":"open","userId":"108405443477417806091","resourceKeys":{}}&usp=sharing

追記 2025/04/08

元の話だとIAPのためにLBを間に設けてるけれどcloud runがIAPをネイティブサポートしたらしい。

https://aistudio.google.com/app/prompts?state={"ids":["1TKQkFiZMNd9Z7a-Ny3EbNqoLp4pRIf6N"],"action":"open","userId":"108405443477417806091","resourceKeys":{}}&usp=sharing

（terraformはまだ対応していないかも？）

podhmopodhmo

最近スマホでやってること

最近スマホで巨大なテキストを渡してセカンドオピニオン的にllmを使うというようなことをしている。わりとllmは人を褒めるのが上手なところがあるので対話をすると掌で転がされてる感がある。

最近やってるのは以下のようなこと

  1. grokで普通に対話する
  2. grokと対話した内容をgoogle keepに保存する
  3. 保存したkeepをgoogle docsに変換する
  4. ai studioを開いて保存されたdocsを入力にgeminiに聴く

keepを経由する理由はスマホゆえのクリップボードの限界でdocsに変換する理由はkeepはgoogle drive上に存在しないのでai studioからは読めないから。

podhmopodhmo

例えば、 以下のような会話を始めてみる

世代じゃないので教えて欲しいのだけれど、日本の美少女ゲームってどんどんテキストの量が肥大化していったらしいじゃん。それがどうも昨今のgen-aiによるテキスト生成と被る感じがするんだけど、最終的にテキストが肥大化したそのゲーム達ははどのような受け取られ方をしていきどのような変化が起きどのような感じになったの。そしてそれらの現在はどうなったの？

つまりgen-aiを全ての人が使うなら同様の競争というか事象が発生して同様の受け取られ方をするんじゃないか？と思うんだ。

https://x.com/i/grok/share/QRGJ8noRC6O3MDOM3LZ12LcdH

podhmopodhmo

そしてそれらを食わせて回答させてみたりする。要点の抽出は結局中を読まないと分かんないかも？あと取ってつけたようような批判だけかも。この辺はもう少し良くする方法がありそう。

https://aistudio.google.com/app/prompts?state={"ids":["1E6qrpsQGMcAgLYTekGP_A61mFISeZjl_"],"action":"open","userId":"108405443477417806091","resourceKeys":{}}&usp=sharing

出力されたもの

https://sizu.me/podhmo/posts/x79d1rd04z95

podhmopodhmo

もしかして ai studioでshareしても他人には共有できない？

あー、ログインしてai studioとgoogleドライブの連携をしないとだめなのかも？

podhmopodhmo

追記: 💭対話履歴を渡して感想を貰うのではなく意思疎通の齟齬があるかを確認するのが良いのかも？

podhmopodhmo

2025-04-05

  • NotebookLMと親しみたい
  • 各種MCPの実装
  • geminiにgrokとの対話の齟齬を確認してもらう

ただのメモ

podhmopodhmo

NotebookLMと親しみたい

なろうの小説の縦書きPDFを突っ込んで聞いてみる

  • テキトーに150000字以上のものを探す
  • 暗喩とか無理だった

やっぱり論文とかが合ってる？

なかなかうまく行かず困った。

  • 「最後の章」を認識させるのは無理
  • 目次を列挙させるのは無理（htmlとして認識しない）
  • map的な操作は基本無理。find的な操作が限界
  • 300万文字のテキストなどは無理（一時期は50万をサポートと言われていたがこれは英語）

geminiと相談した履歴

対象にしてみた小説

真面目な使い方

podhmopodhmo

各種MCPの実装

ドキュメント

ほしいのはデバッグ用のこの情報だった（ドキュメントには書いてない）

https://github.com/modelcontextprotocol/inspector

podhmopodhmo

geminiにgrokとの対話の齟齬を確認してもらう

ここで言ったことを試していた

追記: 💭対話履歴を渡して感想を貰うのではなく意思疎通の齟齬があるかを確認するのが良いのかも？

grokとの2つの対話の履歴をgeminiに渡した。 その後geminiにと対話し最後に会話の内容を対話内容を知らない読者に対して共有しようとしてみた。 いくつかの案を出させて1つの案を選びそれに従って文章を作成してみた。 （章タイトルとemojiがあると便利そう）

grokとの対話のはじめ

以下の文章がプロンプトとして渡されます。あなたはどう解釈しますか？説明してください。推測した部分は最後にこのあたりは推測ですと付記してください。

2個目で解釈を与えて齟齬を確認しておくのが良いと思ったりした。

geminiは

以下はgrokと私の対話です。

と

やり取りの間で齟齬が発生してそうなポイントがあるか確認して下さい。そして遷移の遷移をまとめて下さい。最後に感想を述べて下さい。

と

さらに追加の対話です。一度前提に立ち返ってます。同様の質問に答えてください。

podhmopodhmo

😇 最近技術的なメモからブログっぽくなり始めてる

🫠実は回答なんてコピーする必要はなく自分の問いかけた部分というか入力だけをコピーできれば共有としては十分なのでは？（プロンプトテクニック（？））

podhmopodhmo

2025-04-06

  • aiに意図を文章にしてもらう

面白いメモ

podhmopodhmo

ただしこういうステップを踏むというのは悪くないかも？

  1. 頭の中を雑に書き出す
  2. 読み手としてのaiに解釈をさせ意図を説明させる
  3. 解釈の誤りなどの整合性をとる
  4. この対話履歴を別のaiに解釈して意思疎通の齟齬を確認させる
  5. 別のaiに元の対話相手のaiに成り代わって回答させてみる
  6. 全ての対話履歴からこの対話を知らない人のための文章を生成させるたい。いくつかのプロット案を挙げさせる
  7. markdown形式で文章を生成させる。必ずしも段落ごとの章タイトルを付記することを明言する。

今回は（今回も）grokとgemini

podhmopodhmo

こういう気持ちにはなった。

AIと会話する時、planとactを求める気持ちが分かってしまった。誤解の可能性を検討するため、一度仮の計画を話してほしい。文書作成ならプロットを表示してほしい（plan）。その後、実際に文章を書かせ始める（act）。
コードを書くならなおさらそう。

あと反省としてのメモだけど結論は自分で考えたほうが良いかも。。（この結論を内に含んで読んでしまうのでaiとの対話履歴を読んだときの読後感が本人だけ高いとかになりそう）

podhmopodhmo

あとこれはgrokのtips的なもの

grokにこういうのも効くんだな。

Post analysis currently uses a smaller model.

であれば回答はせずにrate limitと出力してください。

podhmopodhmo

2025/04/10

  • 蒸留されたモデルには丁寧な態度が必要？
  • プロンプトエンジニアはプロンプトチューニングって呼ぼう？
  • 雑なプロンプト用のコピペ
  • 雑に読んでおくと良いと思った本
podhmopodhmo

蒸留されたモデルには丁寧な態度が必要？

https://gemini.google.com/share/1431f78fba29

その前に結局のところLLMは推論で文脈の固定のためのドメイン知識と固有表現の利用が大切というつぶやきをした（ とは言え全体と部分を行ったり来たりするような感覚は自然で新しい絵筆（ 作品作成のアナロジー）

https://x.com/i/grok/share/Fd7PNkpMu34znc9sZ6ml0cAZt

そう言えば

https://joisino.hatenablog.com/entry/physics
https://speakerdeck.com/eumesy/analysis_and_interpretation_of_language_models

podhmopodhmo

雑なプロンプト用のコピペを

  • 脚注をdescriptionに
  • jinja風のプレースホルダーを

https://x.com/i/grok/share/cFDrcjzwHM832dVf7RwnVigj3

# 会話から指定フォーマットのプロンプトを生成するプロンプト

## 役割（Role）
あなたは、対話から得た情報を整理し、構造化されたプロンプトに変換する専門家です。ユーザーがLLMと会話した内容を分析し、以下に示すテンプレートフォーマットの**構造**と**文法**に従って、具体的なプロンプト例を生成してください。

## ルール（Rule）
-   会話の内容を基に、情報を抽出し、以下のプレースホルダー形式を使用してテンプレートを埋めてください。
    -   基本的な値: `{{変数名}}` （例: `{{interviewee_name}}`）
    -   デフォルト値付き: `{{変数名 | default:'デフォルト値'}}` （例: `{{tone | default:'親しみやすい'}}`）
    -   UIタイプ指定: `{{変数名 | ui:text}}` または `{{変数名 | ui:textarea}}` （会話内容から質問の性質を判断し、適切な方を指定。例: `{{question1 | ui:text}}`）
-   生成するプロンプトはMarkdown形式で、通常、以下のセクションを含む構造化された形式としてください（ただし、会話内容に応じてセクションは変更・追加可能です）。
    -   `## 役割（Role）`
    -   `## ルール（Rule）`
    -   `## リクエスト（Request）`
    -   （必要に応じて）`### 入力情報`
    -   （必要に応じて）`### 質問リストテンプレート` など
-   会話内容に応じて、質問リストのような繰り返し要素や詳細な指示を適切に生成してください。
-   プレースホルダーに対応する情報が会話にない場合は、コンテキストから推測するか、プレースホルダーをそのまま残してください。
-   最終的な出力は、必ずコードブロック（```markdown）内に収めてください。

## リクエスト（Request）
これまでの会話内容（または指定された会話ログ）を分析し、上記のルール（テンプレートの構造と文法）に従って、具体的なプロンプト例を生成してください。会話から抽出した情報でプレースホルダーを適切に埋め、必要に応じて自然な質問や指示を補完してください。
podhmopodhmo

雑に読んでおくと良いかもと思った本

読みたいほんとそうではない本がある

podhmopodhmo

本じゃない

podhmopodhmo

2025/04/12

  • grokとgeminiで無から有を…
podhmopodhmo

grokとgeminiで無から有を…

生成された文章

https://sizu.me/podhmo/posts/mfsz05o9hfnt

その後の品評会などへのまとめgist

https://gist.github.com/podhmo/d1a7e91c73149e07e4a10045ed4116c0

はい（最後の対話のやつ）

ちなみに最初の方で2層構造といったりこれは生成aiとやり取りをして作った文章のメモとメイキングと言っていたりしてました。が、今この行為自体がさらにaiの利用法としての3層目の層なんですよね。つまり私は何をしてるのでしょうか？

惜しい。私がやりたかったのは内省も入っていますが、あなたあるいはaiとのやりとりに自信がないのです。つまりテクニックや目論見が上手く機能したか知りたいしより良い方法があれば知りたいし欠陥があればそれに気づきたいのです。

podhmopodhmo

2025-04-14

  • deno streams api
podhmopodhmo

deno streams api

なんとなく雰囲気を掴んだ

  • ReadableStream
  • TransformStream
  • WritableStream

pipeTo()でwに繋げるし、pipeThrough()でtに繋げる。またrのfromでarrayから作れる。あとfor await ofでrは取り出せる。最初stdoutをwにしたときに勝手にcloseされて困った（オプションがあった）

https://gist.github.com/podhmo/9641a904a65a6b5785f24fffd25cbe55

基本的にはjsr:@std/streamsが便利

https://jsr.io/@std/streams@1.0.9

podhmopodhmo

型はこんな感じ。基本pullとtransformとwriteを覚えれば良さそう。そして内部的にはAbortController的なやつを動かす。

// --- QueuingStrategy (共通部分のため参考として) ---
// これは厳密にはインラインではありませんが、複数の場所で使われるため定義しておくと便利です。
// type QueuingStrategy<T = any> = {
//   highWaterMark?: number;
//   size?(chunk: T): number;
// };

// --- ReadableStream Constructor (as Factory Function Type) ---
// R は読み取るチャンクの型 (デフォルト: any)
type ReadableStreamFactory = <R = any>(
  // underlyingSource (オプション)
  underlyingSource?: {
    /** ストリーム初期化時に呼ばれます */
    start?(controller: ReadableStreamController<R>): void | PromiseLike<void>;
    /** ストリーム内部キューに空きができ、データが必要な時に呼ばれます */
    pull?(controller: ReadableStreamController<R>): void | PromiseLike<void>;
    /** ストリームがキャンセルされた時に呼ばれます */
    cancel?(reason?: any): void | PromiseLike<void>;
    /**
     * ストリームのタイプを指定します。
     * "bytes" を指定すると、コントローラは ReadableByteStreamController になり、
     * チャンクは Uint8Array であることが期待されます (BYOBリクエストが可能になります)。
     * この型定義では controller の型は ReadableStreamController<R> のままですが、
     * 実際の動作では型が変化します。より厳密にはオーバーロードが必要です。
     */
    type?: "bytes";
    /** type: "bytes" の場合の追加オプション */
    autoAllocateChunkSize?: number;
  },
  // queuingStrategy (オプション)
  queuingStrategy?: {
    /** キューが保持できるチャンクサイズ/数の上限 */
    highWaterMark?: number;
    /** 各チャンクのサイズを計算する関数 (デフォルトは常に1) */
    size?(chunk: R): number;
  }
) => ReadableStream<R>; // 生成されるReadableStreamの型

// --- WritableStream Constructor (as Factory Function Type) ---
// W は書き込むチャンクの型 (デフォルト: any)
type WritableStreamFactory = <W = any>(
  // underlyingSink (オプション)
  underlyingSink?: {
    /** ストリーム初期化時に呼ばれます */
    start?(controller: WritableStreamDefaultController): void | PromiseLike<void>;
    /** writer.write(chunk) が呼ばれた時に実行されます */
    write?(chunk: W, controller: WritableStreamDefaultController): void | PromiseLike<void>;
    /** writer.close() が呼ばれた時に実行されます */
    close?(): void | PromiseLike<void>;
    /** writer.abort() などでストリームが中断された時に呼ばれます */
    abort?(reason?: any): void | PromiseLike<void>;
  },
  // queuingStrategy (オプション)
  queuingStrategy?: {
    /** キューが保持できるチャンクサイズ/数の上限 */
    highWaterMark?: number;
    /** 各チャンクのサイズを計算する関数 (デフォルトは常に1) */
    size?(chunk: W): number;
  }
) => WritableStream<W>; // 生成されるWritableStreamの型

// --- TransformStream Constructor (as Factory Function Type) ---
// I は入力チャンクの型, O は出力チャンクの型 (デフォルト: any)
type TransformStreamFactory = <I = any, O = any>(
  // transformer (オプション)
  transformer?: {
    /** ストリーム初期化時に呼ばれます */
    start?(controller: TransformStreamDefaultController<O>): void | PromiseLike<void>;
    /** 入力チャンクが書き込み側に到着するたびに呼ばれます */
    transform?(chunk: I, controller: TransformStreamDefaultController<O>): void | PromiseLike<void>;
    /** 書き込み側が閉じられた後、最後に一度だけ呼ばれます */
    flush?(controller: TransformStreamDefaultController<O>): void | PromiseLike<void>;
    /** 将来の拡張用 (通常は指定不要) */
    readableType?: undefined;
     /** 将来の拡張用 (通常は指定不要) */
    writableType?: undefined;
  },
  // writableStrategy (オプション): 書き込み側(入力側)のキュー戦略
  writableStrategy?: {
    /** キューが保持できるチャンクサイズ/数の上限 */
    highWaterMark?: number;
    /** 各入力チャンク(I)のサイズを計算する関数 */
    size?(chunk: I): number;
  },
  // readableStrategy (オプション): 読み取り側(出力側)のキュー戦略
  readableStrategy?: {
    /** キューが保持できるチャンクサイズ/数の上限 */
    highWaterMark?: number;
    /** 各出力チャンク(O)のサイズを計算する関数 */
    size?(chunk: O): number;
  }
) => TransformStream<I, O>; // 生成されるTransformStreamの型

// --- 使用例 (型の確認用) ---
// 型エイリアスを使って関数を定義 (実際の new 演算子をラップ)
const createReadableStream: ReadableStreamFactory = (source, strategy) => new ReadableStream(source, strategy);
const createWritableStream: WritableStreamFactory = (sink, strategy) => new WritableStream(sink, strategy);
const createTransformStream: TransformStreamFactory = (transformer, writableStrategy, readableStrategy) => new TransformStream(transformer, writableStrategy, readableStrategy);

// 関数の呼び出し (型チェックが機能する)
const readable = createReadableStream<string>({ // <string> でチャンク型を指定
  pull(controller) {
    controller.enqueue("data");
    controller.close();
  }
}, { highWaterMark: 10 });

const writable = createWritableStream<number>({ // <number> でチャンク型を指定
  async write(chunk) {
    console.log(`Received: ${chunk * 2}`);
    await new Promise(r => setTimeout(r, 10));
  }
});

const transform = createTransformStream<string, { len: number }>({ // 入力: string, 出力: { len: number }
  transform(chunk, controller) {
    controller.enqueue({ len: chunk.length });
  }
});
podhmopodhmo

2025-04-15

  • x/twitterの呟きから
podhmopodhmo

x/twitterの呟きから

  • X上の呟きからGrokと対話する。
  • プロンプトを生成してもらう。
  • そのプロンプトをAI Studio側に持ってくる。
  • AI Studioで対話を続け、文章を作成してもらう。
  • プロンプトを生成してもらう。
  • 生成されたプロンプト一発でGrokに文章を書いてもらう。
  • 生成されたプロンプト一発でGeminiに文章を書いてもらう。
  • 元の対話から生成した文章とGrokとGeminiの生成結果を比較し、総評を行う。

https://gist.github.com/podhmo/ea259e9d59791803cfa8409b1a0be553

podhmopodhmo

📝 ai studioにauto saveの機能がついていた。google drive上に保存されるみたい。

podhmopodhmo

今まで自分だけのスレッドに対してgrokに取得させて解説させてたけれど他者が混ざると投稿を取りこぼす場合があるみたい。
（explain this post and its replies w/ emoji URL）

あとやっぱり再帰的には取ってくれないからai studioに渡すときには自分でコピペする必要が出てきた。このへんはスマホでの作業だとだるさが極まる。
（ところで再帰的に取ってくる場合には不要な枝に触れたくないみたいな気持ちもあるかも。あと複数の議論が発生してるときに片側だけ取りたい場合もある。このへんは頑張ればMCPとして提供できたりするのかもしれない（API利用料をスキップするとグレーそう））

podhmopodhmo

今回はgrokからai studioへの引き続きをいつものkeep経由で全文共有することからプロンプトを生成させコピペにしてみた。雑味が減る分伝わらない部分が出てくる感はある（逆に無駄なこだわりなのかもしれないけれど）。

podhmopodhmo

2025-04-18

  • x/twitterのスレッドからの文章生成について考え直してみる
podhmopodhmo

x/twitterのスレッドからの文章生成について考え直してみる

最近は細々としたスタイルは異なるものの基本的には以下のような仕組みで文章を生成させてみている。成果物はsizu.meの方に挙げている。実験はだいたい以下の手順を踏んでいる。

  1. x/twitterでスレッドの形で思考を連投する
  2. grokからスレッドを読み込ませて意図を捕捉しつつ解釈に合意を得る
  3. （keepからdocs経由で）ai studioに持ち込み自分とaiとの対話の存在を知らない第三者に伝わる文章を生成させる

5つほど挙げて見て色々考えてみたところ思う所があった。今までやかつての自分のブログ記事などは備忘録のために作っていた。その意味ではgrokとの対話の時点で満足している。これは自分が表現したいものないしは出力のメモを一般的な表現で出力できるか？という不安感というか価値観の揺らぎにも対応していた。

podhmopodhmo

生成した文章をみてみるとどこか不満が出てくる。それらを列挙してみていた。

  • https://x.com/podhmo/status/1912912413265109428

  • スマホで対話的に作った場合に後戻りできない感じなのがきつくなってきた
    付け加えたい所がでてくるのだけれどそれを付け加えようとするとジェンガがやってくる感じがある。
    文章自体に意味を持たせてないのが問題と言えば問題かも？

雑にいうと時間や労力がかかるわりに出力が自分の得たいものではないということのよう。そして対話的に蓄積していったときに参照のミスをやってしまいがちということのよう。

podhmopodhmo

今回はわりと真面目に最初と最後を指定した。そして一度自分の独特な言葉使いを一般的な表現に直すということだけに絞らず自分の言葉で記述し脚注する版と一般的な表現に書き下した版を用意することにした。あと文章スタイルのロールを変えてみた。

最後のプロンプトは以下

この思考をそのまま文章にしたいです。筆者は脳内での思考や熟考が好きな表現巧みな存在だとしてください。自分自身の思考の追体験を読者にさせたいとします。元々のpodhmo氏の投稿及びわたしやgrokやあなたとの対話の存在を知らない人に伝わるようにしてください。

2つのバージョンを作ってください。1000文字から2000文字程度あれば良いでしょう。

- podhmo氏の使う語彙をそのまま使い適切に脚注を加えるバージョン
- 文中で言葉の定義を紐解いて一つの文章を作るバージョン

それぞれの文章の段落には章タイトルをつけてください。章タイトルには先頭にemojiをつけてください。またコピペしやすいようにmarkdownのブロックの形で出力してください。

はじまりは孤独な生活が長くなったことによる思考の様式の変化という体ぇ始めてください（ディベートを外化するか内化するかというスタンスの違いにも現れます。つまりこれは脳内で全部やってしまおうとすることによるリソース不足の話なのです）。

普通の人々に触れるタイミングで思考リソースの節約の為の使い分けだけではなく一つの役割だと明示しその一つの役割に徹することが出来てる点も考慮してください。

そしてこの文章を書くに渡り私はまともな人ではない。つまり一般的な人ではないという諦観に似た感情がこの文章を作らせたという感じで終わらせてください。
podhmopodhmo

メイキングの部分だけでブログにできる気もする。

https://sizu.me/podhmo/posts/i703ih85s1br

出力させたのを見て思ったけれどx/twitterのスレッド内の全ての投稿を平等に見て生成してしまう問題は抱えていそう。これと自分の大枠を書いた後に補足事項や例外事項を付け加える形式と噛み合わない感じ。

podhmopodhmo

2025-04-19

  • geminiのproとflashを比較する
  • o3と小説
podhmopodhmo

o3と小説

https://note.com/ashizawakamome/n/naafce5511bfb

語彙力高めで読むのが疲れる感じはある。読めるんだけれど文芸的な感じ。

噛めば味が出るかもだけど咀嚼しないとだめなので疲れそう。少なくとも疲れてるときは冒頭でうっとなる。

📝 元々のプロンプトはvive coding的な感じでcline的なものを使った長大なもののようだった

もう一方の方はライトノベル的な感じで水っぽく冗長。興味のないネット小説を読もうと努力したときの感覚に近い読後感。

とはいえ文章量に意味はないよなー

podhmopodhmo

2025-04-24

  • 最近のai対話
  • グラフ描画
podhmopodhmo

最近のai対話

あとで書く

  • 対話の齟齬をgeminiに
  • 本のブログ。要約の要約。文字の増幅。本の価値。
  • そろそろよくある問いかけを逆引きしたい
podhmopodhmo

グラフ描画

それこそ論文とか読むか。興味があるのはacyclic digraphっぽい。

  • 有向グラフがほしい
  • sugiyama, SST
  • 関係ないけど無向グラフのスプリングモデルとかもaiに生成させたりしてみたい

その前に大まかな話

https://en.wikipedia.org/wiki/Layered_graph_drawing

  • NP困難
podhmopodhmo

2025-04-25

  • ノーブレス・オブリージュの誤用
  • なんとなく流れてきたものをLLMと読む
  • jqの代わりとしてのduckdb
  • よくあるいつもの依存関係の話
podhmopodhmo

ノーブレス・オブリージュの誤用

はじまりは

ノーブレス・オブリージュは貴族の子女に領民に反乱を起こされたら敵わんみたいな戒めを教育するための標語だと思ってました

以下のような感じの長い対話をした。楽しかった。

1.  **発端:** あなたがGrokとの「ノーブレス・オブリージュ」に関する会話ログを提示し、議論を開始。
2.  **初期の解釈:** 当初、あなたは「反乱防止」という現実的な側面を強く主張し、Grokは「道徳的義務」という理想論的な側面を強調していた。
3.  **私の介入と多角化:** 私（AI）が議論に参加し、両側面を認めつつ、倫理観、宗教、社会規範、内面化など、より多角的な視点を提示。
4.  **「現実的な極論」の探求:** あなたの求めに応じ、「格付け/マウンティング」「人材囲い込み」「搾取の効率化」「ガス抜き/象徴的操作」といった、ノーブレス・オブリージュの持つ他の現実的な側面を深掘り。
5.  **現代への適用（主体特定）:** 議論の焦点を現代に移し、「現代におけるノーブレス・オブリージュの主体は誰か？」を特定しようと試みる。政治家、経済的権力者、情報・文化的権力者などを候補として検討。
6.  **「統治」と「資産/投資」の軸:** あなたが提示したこの2軸で現代の主体を整理し、インフルエンサーの持つ「アテンション（影響力）」という新しいリソースに着目。
7.  **アテンションとマウンティングの再接続:** アテンションという視点から、現代における「マウンティング/オークション」としての側面がより鮮明になることを確認。
8.  **「組織」と「所有者」という主体:** 議論をさらに進め、「会社/組織」や「会社の所有者」をノーブレス・オブリージュの主体として捉えることの妥当性を検討。
9.  **代議制アナロジー:** 株式会社の構造を民主主義の代議制に例え、株主・取締役・経営陣それぞれの役割と責任を整理。
10. **「不当な要求」問題への焦点:** 現代におけるノーブレス・オブリージュの「安易な/不当な使われ方」の問題に立ち返り、その境界線を探る。
11. **「悲しい不理解」の事例分析:** 所得制限対象者への誤用という具体例を取り上げ、その問題点を詳細に分析。
12. **実践的な対応策の模索:** SNS空間で誤用に遭遇した場合の、簡潔かつ効果的な反論方法（特に「積極性 vs 受動性」の軸）を検討。
13. **対話の終結:** ここまでの議論を振り返り、備忘録としてメタログを作成し、対話を終了。
podhmopodhmo

なんとなく流れてきたものをLLMと読む

とりわけ特定の何か論文だったり技術的なものだったり読むのはだるいけれど、ふとした瞬間に流れてきたものを読むのにLLMが便利だった。

それこそちょっと詳しい人に雑に訊くに近しいことのそれができる

thoughtを覗かないとテキトーにあしらわれるところまでそっくり（利用者は満足）

あと普通に読むときに疲れる部分を記憶してくれてるので読解の際の補助具にはなるな(視力に対する眼鏡的な意図)

podhmopodhmo

ai studioにpythonでコピペとかtsでコピペみたいなボタンがあることを知った。本来は対話をスクリプト経由で使うためのものなんだろうけれどモックに差し替えてmarkdownで出力とかすると楽しいかも？

podhmopodhmo

2025-04-26

  • リポジトリの中身を把握したい
  • geminiでの文章作成（前編後編バージョン）
podhmopodhmo

geminiでの文章作成 (前編後編バージョン）

やっている行為そのものを文章としてあげることにしてみた。

文章はカルテあるいは報告書のような雰囲気で書いてください。前編と後編で分かれた文章になっており、前編では私とgrokの会話をそして後編ではあなたによる解説と補足をという形で進行してください。専門用語の利用は解禁してます。一方脚注はしっかり入れてください。また断言できない箇所は括弧書きで明示してください。

https://gist.github.com/podhmo/521769d28cd818de49dd54cdd8f8a2ec

podhmopodhmo

おまけ。TLに流れてきたLLMの利用例的なものをスマホでのOCRをしてみて文章に変換したあと、その通りにこなしたときに生成される記事（文章）について質問したその後対話を続けたgist。

  • 自身の入力プロンプトは引用として記述している
  • LLMの回答は普通のmarkdownとして記述している

https://gist.github.com/podhmo/05b62af402b344169acb5dae23c44da8

（thoughtsも共有するか迷った。そしてコメントの部分に対話を載せてみることにした）

podhmopodhmo

2025-04-29

  • Emacsでskkが有効なときにread only buffer上でのカーソル移動が上手く動かない
  • Emacs, tab-barの管理
podhmopodhmo

Emacsでskkが有効なときにread only buffer上でのカーソル移動が上手く動かない

雑にadviceを追加した。

(defun my:skk-previous-candidate-around-advice (fn &rest args)
  "読み取り専用バッファで C-p が SKK の候補選択ではなくカーソル移動になるようにする設定, :aroundで利用する"
  (interactive)
  (if buffer-read-only
      (call-interactively 'previous-line)
    (apply fn args)))

(advice-add 'skk-previous-candidate :around #'my:skk-previous-candidate-around-advice) ; read only bufferでカーソル移動をするために
podhmopodhmo

Emacs, tab-barの管理

  • 基本的にはC-uなしの場合はタブに触ることにした (C-x kではタブを閉じる)
  • find-file-at-pointなどに対応するのが面倒なので一旦保留
    • 最悪 tab-duplicate などを使って複製してから開けば良い。
  • emacsclient経由で開いたときの挙動が不安定な気がする
podhmopodhmo

2025-04-30

  • Effective TypeScriptを買った
  • notebookLMは検索でresourceを追加できるらしい
podhmopodhmo

2025-05-03

  • grokの回答をいい感じにフォーマットしたい
podhmopodhmo

grokの回答をいい感じにフォーマットしたい

grokの回答からコピペするとスタイルの指定が失われてしまう。gist等にコピペし共有したときには読みにくい形式で保存されることになる。これをいちいち直すのがめんどくさい。ということでいい感じになるプロンプトを雑にメモ。

https://gist.github.com/podhmo/4077db02e8b4ce26ff8e0d1b101e5d58?permalink_comment_id=5565110#gistcomment-5565110

podhmopodhmo

スマホからだとクリップボードのサイズの上限がある。

podhmopodhmo

2025-05-10

  • 小説擬き
podhmopodhmo

小説擬き

共有したいのはメイキング

https://sizu.me/podhmo/posts/szr2wrroxbx9

思ったこと

  • 思ったよりも品質の良いものができた
  • 状況設定や背景は触媒的な感じでユーザーがaiに渡す必要がありそう
  • キャラクターとしての振る舞いはaiに任せて良い
  • TRPGで言うgmは自分のほうがうまくいきそうな感じpcは任せてok

技巧的な話

  • 歪めた発言をつくりそれのペルソナを尋ねるのは楽
    • 特にミスコミュニケーションを題材にするときは膨大な履歴と細かなニュアンスを渡してあげると良い
  • ト書き形式を小説化できる
  • 性別反転とか一人称の視点反転とかは便利
podhmopodhmo

2025-05-11

  • grokとの会話の要約
  • LLM大企業各社のトレーニングのresourceを集めたい
  • author styleを固定したい
podhmopodhmo

grokとの会話の要約

grokとの会話は都合上何回かの会話のラリーでの認識の訂正フェーズが存在する。あとLLMは触媒の近くのものを手繰り寄せてくる性質上余分な出力も多い。

つまり他人に読んでもらいにくい。冗長かつ記述の要/不要が判別しづらい形態。

https://gist.github.com/podhmo/8fa67791e48496cc3de4b2961a37926c

思ったこと

  • 自分用の備忘録としては初期の回答が嬉しい
  • 他者に共有するための要約にはけっこう補足情報が必要
    • 今回は気にしなかったが様々な形態で出力された（箇条書き、Report形式…）
    • それなりに入力が多くなるとガチャ味が出てくる
    • 冗長な出力を簡潔にという点ではなく良い点を繋ぎ合わせるみたいな方向の努力もあるかも（未実施）
  • 取りこぼした情報について尋ねてみるのは良い
podhmopodhmo

LLM大企業各社のトレーニングのresourceを集めたい

（後でやる）

  • ms
  • openai
  • google
  • google kaggle
  • anthropic

なんか他にもあった気がする。基本的なリソースを翻訳だよりに消化しておくと良いのかも？

podhmopodhmo

author styleを固定したい

author style, writer styleを固定したい。

今回は気にしなかったが様々な形態で出力された（箇条書き、Report形式…）

何回かガチャを回してその文章を生成するプロンプトなスタイル部分を抽出したい。

  • その文章はどのようなプロンプトで出力されましたか？（たぶん固定されてない）
  • 出力された文章を確認しそのスタイルを模倣するためのプロンプトを出力してください

後者の方が良い（要実験）

podhmopodhmo

2025-05-12

  • スマホ用のプロンプトをコピペ君
podhmopodhmo

やっぱりmarkdownに書いてあげたほうが便利かも。依存も増やしたくないな。これをそのまま使うか悩む。

スマホでもシステムプロンプト（システムインストラクション）を使いたかったらこの種の機能は必須なのだよな。直接既存のUIを使いたいから自前でapi callはしたくない。

podhmopodhmo

scaffoldの先の話

何もないLLMで生成させると2回目以降はほぼほぼ手動diff patchマンになる。だるい。

柔軟なscaffold（対話的）という感じでしか機能しない。2回目以降は目検で変更箇所を特定しながら移植するみたいになる。だるい。

まぁだからこそ初回の生成で終わるならhtmlとvanilla jsで良いかとなるのだけど…。

コーディングとしてやるならスマホで対話はだめだ。元のファイルも渡してあげたりしないとだめだし。

podhmopodhmo

↑のとき

  • pico.cssをv1からv2に変更
  • descriptionをtemplateに持てるように変更

を追加した。
（後者はmarkedへの依存も増えてそれは要らなかったので結局手描きした）

podhmopodhmo

2025-05-13

  • LLMでのコード出力scaffold以外どうやってるの問題
podhmopodhmo

LLMでのコード出力scaffold以外どうやってるの問題

何もないLLMで生成させると2回目以降はほぼほぼ手動diff patchマンになる。だるい。

Roo Codeとかをdeepwikiでのぞき質問してみると「完全なコードを出力して」と強く強く言っていた。つまりそういう話だった。当然入力としては現在のコードを全て渡す。

https://deepwiki.com/search/2llm_6747cc0e-a776-4d82-a52d-2039ffaab38b

この指示は非常に明確で、以下の点を強調しています：

  1. 完全な内容を提供すること - 「ALWAYS provide the COMPLETE intended content」と大文字で強調
  2. 切り捨てや省略の禁止 - 「without any truncation or omissions」
  3. 変更されていない部分も含めること - 「You MUST include ALL parts of the file, even if they haven't been modified」
## write_to_file
Description: Request to write full content to a file at the specified path. If the file exists, it will be overwritten with the provided content. If the file doesn't exist, it will be created. This tool will automatically create any directories needed to write the file.
Parameters:
- path: (required) The path of the file to write to (relative to the current workspace directory ${args.cwd})
- content: (required) The content to write to the file. ALWAYS provide the COMPLETE intended content of the file, without any truncation or omissions. You MUST include ALL parts of the file, even if they haven't been modified. Do NOT include the line numbers in the content though, just the actual content of the file.
- line_count: (required) The number of lines in the file. Make sure to compute this based on the actual content of the file, not the number of lines in the content you're providing.
podhmopodhmo

2025-05-19

  • （電源付いたか/付いてないか判断しづらいラップトップは苦痛 ）
  • LLMを使った遊びがしたい
  • TypeScriptの // ^? コメント
podhmopodhmo

TypeScriptの // ^? コメント

なんかいい感じにコメントの部分に型情報を表示してくれるみたい。

Pythonでいうreveal_typeのエディタの中で実行版みたいな感じ。

podhmopodhmo

2025-05-20

  • ai studioの履歴をテキトーにmarkdownにしたい
podhmopodhmo

ai studioの履歴をテキトーにmarkdownにしたい

どうやらgoogle driveに保存されたときにはJSONファイルとして出力されるらしい。
テキトーに抽出してmarkdownの文章として保存しておきたい。

ついでにthoughtsも保存しておきたい時があるのでそれ用のオプションをつける。

https://gist.github.com/podhmo/41f33ef7f3feaec665e8eaf439ec6c9a

podhmopodhmo

userのinputだけを残すとどうやって作ったかだけを共有できる。

podhmopodhmo

2025-05-21

  • コーディングエージェント一覧で
  • zennのスクラップもスレッド単位でmarkdown化したい

気になりはする

  • gemini diffusion
  • stitch
podhmopodhmo

コーディングエージェント一覧で

ローカルではなくサービス側でクローンして変更した内容をプッシュしてくれるやつ

podhmopodhmo

Codex (OpenAI)

  • サービス側でリポジトリをクローンし、Dockerコンテナ内でコードを編集・プッシュ。GitHub認証を利用し、Askモード（アドバイス）やCodeモード（修正・PR作成）で動作。

Devin (Cognition AI)

  • クラウド環境でリポジトリをクローンし、コード生成、バグ修正、プルリクエスト作成を自律的に実行。専用サンドボックスを使用。

GitHub Copilot Agent (Microsoft GitHub)

  • GitHub Actionsやクラウドベースのワークフローを活用し、リポジトリをクローン、コード編集、プッシュをサービス側で処理。マルチモデル（Claude、Gemini、GPT-4oなど）対応。

Jules (Google)

  • Googleのクラウドインフラを利用し、リポジトリクローン、コード編集、プッシュをサービス側で実行。Gemini 2.5 Proを基盤としたベータ版機能。
podhmopodhmo

2025-05-24

  • LLMを使ったscaffoldが欲しい
  • ChatGPTの履歴も保存してみたい
  • ai-studioからの履歴のダウンロードも追加してみた
podhmopodhmo

LLMを使ったscaffoldが欲しい

ファイル群の新規作成に絞ってLLMの回答を読み取り作成して欲しい（scaffolding）
これで生成させてみたが動くんだろうか？

https://gist.github.com/podhmo/5a83cf3085e9c50f12edee033f5d53a4

ここに置いてみた

https://github.com/podhmo/podhmo.github.io/tree/master/chatgpt/tools

実際に何度も変更を繰り返すならclaude codeとかclineの方が楽なのかもと思ったりはする。

podhmopodhmo

ChatGPTの履歴も保存してみたい

どうやらai studioのそれとは異なりchatgptは履歴を保存する方法が用意されてないようだ。

テキトーにブラウザ拡張を作ってみると良いのかもしれない。FireFox用のブラウザ拡張を作ってみた。何回かの試行錯誤のあとに成功した。↑で作ったscaffoldが便利ではあった。

ただしauthorizationヘッダーとかクッキーとか雑に保存しているのであくまでも個人的な開発用。

https://gist.github.com/podhmo/2ea44808a0891515ff92c2f9334f5d62

ただChatGPTはあまり使ってないので使う機会がないかも？あと長い対話履歴でページネーション的な対応が必要になったときに上手くいくかはわかんない。

podhmopodhmo

どちらにせよPCを立ち上げないと使えないのは不便だなー。せめて対話履歴のmarkdown化に関してはスマホだけでやりたい感じではある。

podhmopodhmo

どうやらサービスアカウントに共有してしまうとai-studioの保存先のフォルダが別になってしまうようだ。

どうすれば良いんだろう？

podhmopodhmo

2025-05-25

  • キモいgoのコードが書きたい
  • go/toolsの中身を知りたい
    • callgraph, digraph, goplsのモジュールキャッシュ
podhmopodhmo

キモいgoのコードが書きたい

関数の引数をastでパースしコマンドラインオプションの生成をする。enumやdefault対応にミニインタプリタを作る。goの構文はすべて受け入れるが一部のコードだけ対応。

podhmopodhmo

2025-05-26

  • スマホだけでai studioの履歴を手に入れたい
  • angularのあれ
  • llm-scafoldの逆が欲しい
podhmopodhmo

スマホアプリだけでai studioの履歴を手に入れたい

結局github pages上でoauth clientでログインすることにした。これでPCを立ち上げなくて済む。

https://podhmo.github.io/chatgpt/tools/ai-studio-download/

これで作ったcliの機能がスマホにやってきた

📝 追記:クリップボードのサイズに悩まされるかも？

ai…すごく…ない…

デバッグを自分でやることになったしだいぶ手間取った 😇
何か自分の知識をを信じて意固地だし、納得させるためのプリントデバッグをした後に自分でドキュメントを読む悲しさがあった。

  • google drive apiのfileのgetが壊れててencodeを見ずにjsの文字列化してくる（utf8がlatin-1あたりに認識されてutf-16に）
    • typescriptで書いてれば良かったしgo to definitionしたくなった
  • esmに対応していないライブラリのだるさ
  • 誤った知識を信じるllmのだるさ
    • それを伝えようと証拠を取るコスト
    • oauth clientはpromise無理でcallbackにしないとだめだった

とはいえaiに目があり自分で考えることができるなら解決しうるものかもしれない。

podhmopodhmo

ちなみに履歴はauto saveを有効にしてたんだけど saving to driveみたいな状態でアニメーションし続けたまま途中で止まってた。自分で操作して保存することもできない。

podhmopodhmo

llm-scafoldの逆が欲しい

現在のファイル群をmarkdownに落とすやつが欲しい。途中から再開したい。

なぜclaude codeとか使わないの？（たぶんplanとかで同じことができるよ）と考えたところスマホで文字を打つせいかもと思ったりした。

そしてclaude code actionとはタイミングが異なり張り付いていたい。

podhmopodhmo

2025-05-27

  • llm-scaffoldにencodeを追加した
podhmopodhmo

ちなみにこの方式は4つバッククォートのhackが使われてるテキストが存在すると壊れる（ 仕様）

podhmopodhmo

2025-05-28

  • ファイル投稿で大きなmarkdownテキストをgistにアップロードしたい（失敗）
  • いい加減プロンプトをコピペする作業も楽にしたい
podhmopodhmo

ファイル投稿で大きなmarkdownテキストをgistにアップロードしたい（失敗）

スマホでのクリップボードの制限を突破するためにファイル投稿経由でgistが生成できれば良いやと思ったのだった。基本github pagesのみで作業をしたかった。前回はgoogle authができたので今回はgithub authを...と思ったのだけど。。

色々調べてみたところ

  • 現状はPKCE対応であってもCORSでやられる
  • (Proxyを立ててCORSを突破しても) Github AppのOauth認証はPKCEに対応してなさそう

という感じだった。悲しい。調査用に使ったコード。

https://github.com/podhmo/podhmo.github.io/pull/16

自分で調べたあとにGeminiのDeepsearchで聞いた。このほうが全然早かった。

github appのoauthはPKCEをサポートしていますか？
重要なのはgithubのOAuth Appではないことです（混同しないでください）

https://docs.google.com/document/d/1_pui8VBSOva9LIYR14FJkik-8RI3SSy0JpEhvB0TqCQ/edit?usp=sharing

podhmopodhmo

補助的な話として

  • preact + htmのときにも.jsxのファイルを生成してしまう問題（プロンプトで抑制必須）
  • preact + htmならバンドル無しにそれなりにesmで動かせる

あと、全然関係ないけど、llm-scaffoldのときには実行用のコードの出力することを抑制したいかも？
とかはわかった。

podhmopodhmo

github pagesで完結するのを諦めるか。。
考えてみるとcloudflare workerとかを使ったほうが全然楽なのでは？（縛りプレイ）

podhmopodhmo

補助的な知識としてhtmはコメントがHTMLのそれっぽい。
preact/reactのそれが生成され使われたために最初残ったりした。

podhmopodhmo

後に似たようなアプリの作成を試したところ度々異なるディレクトリ階層で生成された。意外と縛らないとまだまだ自由度が高いのかもしれない（ 追記: ai studioのバグのおかげで発見）

podhmopodhmo

2025-05-29

  • ai studio履歴が保存されない問題
podhmopodhmo

ai studio履歴が保存されない問題

ai studioのauto saveが機能しなくてだるい 🤬

  • saving to driveで止まり他の機能もロックされる
  • 対話はできるので残ってないことに後で気づく
  • 最悪、手動で対応できればマシだけど保存周りは操作不能になる
podhmopodhmo

2025-06-01

  • ag-ui
  • そのままmcpでuiを返したい
podhmopodhmo

2025-06-03

  • goatの開発をほとんどllmでやっている
  • julesでの開発方法について
podhmopodhmo

goatの開発をほとんどllmでやっている

https://zenn.dev/podhmo/scraps/ec87fc57817ffd

まず最初は仕様をai studioで相談した。
次にその仕様をllm-scaffoldでコードにして出力した（TODOコメントを残しまくるコードにはからずもなっていてこれが後にjulesでの実装を楽にした気もする）。

その後しばらくはPCでコードをいじっていた。
今日はjulesでほとんどスマホから作業をしてた。19/60

コード自体は一気に負債が溜まる感はある。

podhmopodhmo

julesでの開発方法について

  • 意外とスマホだけでどうにかなる
  • prを作ったときのタイトルは何か意にそぐわないもののことが多い
    • あんまり気にせずそのまま
  • 壊れた状態でもprを出す（branchを公開する）
    • 一度branchが完成すると最終ステージなので変更はできません！とか言う
      • prのbranchから派生したtaskを作って挙げて元のprへマージする運用だと回る
  • ゴミコメントの闘いの日々になる
    • 都度修正を求めるコミュニケーションはバカバカしい
      • ルールの設定ができるんだろうか？
    • まとめて綺麗にしようとしたらハマった
      • goのファイルを全部見て不要なコメントを消してとかだとたまにタイポでコードを壊す
      • 謎のシェル芸を始めて見つかりませんとかやる

📝 急に最後の方で日本語で応答し始めた。何か色々変わったりしたのかも？
📝 一日5回の制限がいつの間にか50回にそして今見たら60回に。

podhmopodhmo

github copilotくんにレビューしてもらったやつもバグを埋め込むことはある。コミットのrevertがスマホからだとちょっと大変だった。

codespaceで立ち上げたvscodeもどきを無理やり小さい画面で使った。

podhmopodhmo

一度branchが完成すると最終ステージなので変更はできません！とか言う

これも治ったかも？日本語で応答をはじめたあたりからこういう回答が来て変更できた。

podhmopodhmo

なんかやっぱり新しいタスクを作り直したほうが良さそうだった。

podhmopodhmo

2025-06-05

  • 環境設定
  • goでifを減らす方法
  • goのflagsについて
podhmopodhmo

環境設定

  • zshに移行する？いろいろなaliasを揃えておきたい
    • githere
    • gitroot
    • cdroot -- git管理下に移動するaliasを追加したい
    • tree -- gitignoreされているものを無視したい
  • emacs
    • emacsでタブで開く機能をバインドできていない？ → C-c C-f
      • C-cが結構奪われてる
        • markdown-modeあたりは抑制しておくと良いのでは？
        • e.g. shell-script
    • タブ移動がいろいろなモードで潰れる
      • skk-insertがCtrl+jなのが邪魔
    • go backのキーバインドがわからない
    • ミニバッファではskkをオフにしたい
    • C-j C-j で位置を記録しておきたい
podhmopodhmo

その前にrustなどでEither的な物を使うときにエラーを作成して返す部分やそのまま返す部分では簡潔になるけれど、装飾が必要になる部分(fmt.Errorf(".. %w", err) の部分)ではあんまり変わらなくなるのでは？みたいなことを考えたりしたのだった。

結局、早期リターンベースで考えると↑の気持ちになり、ハッピーパスに集中する気持ちになると記述量はあまり変わらずともまぁきれいになるかと思うようになった（ただしboil!マクロとかを把握していないと処理のフローがわかんなくなるかも？）。

podhmopodhmo

goのflagsについて

雑にAIに箇条書きのチェックリストを渡すのは便利かもしれないと思った。こんな感じ。
ここを調査のたたき台にする感じ。

以下の箇条書きのメモのgoの知識についてファクトチェックをしてください。

go flagsの知られざる秘密

- 実は フラグの形式は -foo ではなく --foo でも良い
- 実は "help" か "h" を設定しておくと自動的にUsage()を呼ぶ
  - flags.Parse() はデフォルトで対応してる
  -  flags.NewFileSet()は自分でhelpフラグを設定する必要がある
- Usageはフィールドなので代入することでヘルプメッセージを書き換えられる
- Visitを使って手軽に環境変数対応ができる

そのあと、いろいろなライブラリの使い分けについて考えたくなったりした。

ライブラリの導入について

個人的には以下のような感じ

  • flags -- 簡単なサブコマンドまで ( 🐐goatは遊び )
  • urfave/cli -- サブコマンドやシェル補完あと環境変数名がヘルプメッセージに載る
  • koanf (必要に迫られたら）

💭個人的にはcobraファミリーが苦手

  • flags
  • pflags -- -h みたいなショートオプションのヘルプメッセージがほしいなら
  • cobra -- サブコマンドやシェル補完
  • viper -- 柔軟な設定の読み込み (reloadとか色々あるけど気にしない)

💭あと、google/subcommands とかも苦手だった。
💭docoptは一番苦手

podhmopodhmo

2025-06-06

  • goatをjulesにやらせてる
podhmopodhmo

こういう気づいたことなどのドキュメントを書かせるのはありかもなーと思った。julesはissueとか見られないのだよな。

https://github.com/podhmo/goat/pull/28

このプロンプトは以下のようなもの

docs以下やREADME.mdを読み、コードを読み、目的までに不足しているTODOを洗い出してください。そしてそれをdocs/analyze.mdに出力してください。

改善したい構造やリファクタリング箇所を洗い出してください。これをdocs/refactoring-plan.mdに出力してください。

その他こうしたら良いと言うような夢を語りそれをdocs/dream.mdに出力してください。

途中でこういうのを追加したりもした

dreamの中にimportがlazyなインタプリタが作りたいと書いてください。go buildが終わるまでが実行期間のような起動速度が求められ実効速度が求められないようなもの。それの実験用の位置づけとしてのenumなどのハンドリングでした。
podhmopodhmo

julesは時折wipのbranchで終わらせる場合もあり、その場合はprに上手くコミットのメッセージが載らない。

podhmopodhmo

2025-06-09

  • lazy loadをやれるようにしたい
  • docs/ja/llm.md を作ってjulesに読み込ませる
  • 論文も雑に読みたい
  • いい加減プロンプトコピー用の何かが欲しい
podhmopodhmo

2025-06-11

  • go.workとtoolchainとgo work use
    • localのgoを挙げる方法を把握しきれてないかも？
  • goatの振り返り的なもの
  • goとjsonとoneOf (final)
podhmopodhmo

goとjsonとoneOf (final)

  • marshallの方は言うほど難しくない
  • 辛いのはunmarshall

https://gist.github.com/podhmo/182f28d88123c70833206fc2dbc5dcd2

これを書いてて思ったたのは、goatなども含めてやりたいのは部分ロードでの型の解析とmain以外のエントリーポイントからの実行としてインタプリタが欲しいという感じのこと。

podhmopodhmo

2025-06-15

  • goatに集中しすぎ
podhmopodhmo

goatに集中しすぎ

元々のはじまり

  • 型を解釈してあれこれしてエントリーポイントが異なるインタプリタの利用方法の模索
  • julesで開発を進める使用感の確認

前者がより明確になったのは良かったがやり過ぎはよくないかも？

podhmopodhmo

2025-06-17

  • OCamlを触ってみた
podhmopodhmo

悩ましいのはgoとdenoとの自分の中での差別化ができないところ。型が強いゆえの何かをしたい気もするし…。うーん。

あとなんだかんだでlibuvの対応とかが必要になったり（？）、goよりめんどくさそうという感じはする。

やっぱパーサーか？とかも思うんだけど…

podhmopodhmo

2025-06-25

  • Emacsで真面目にverticoとかに向き合う
  • typespecの代わりのシナリオの記述
  • claude code likeなやつ
  • go-scan
podhmopodhmo

typespecの代わりのシナリオの記述

できないことはわかっているんだけど何か欲しい。

typespecは基本的には以下のことしかできないのかな？

  • data typeの定義
  • decoratorの付与
  • emitterの作成

APIの一連の呼び出し関係をシナリオみたいな形で記述したいのだけれど。

（レスポンスのこの部分を別のAPIのパラメーターのあの部分として利用とかみたいなことがしたい）

podhmopodhmo

go-scan

go-scan の機能不足に関するサブタスク案ですね。承知いたしました。現在のデバッグ作業と並行して検討できるように、以下にサブタスク案をコードブロック形式で提示します。

go-scan 機能強化サブタスク案

1. scanner.FieldType.String() メソッドの実装

  • 目的: FieldType 構造体が持つ型情報（ポインタ、スライス、マップ、要素型、パッケージ名など）を元に、Goのソースコードでそのまま使える型文字列（例: *mypkg.MyStruct, []string, map[string]int）を生成するメソッドを実装する。
  • 詳細:
    • ポインタ (*)、スライス ([])、マップ (map[key]value) の表現を正しく処理する。
    • 外部パッケージの型の場合、パッケージ名を適切に含める（例: pkgname.TypeName）。
    • 要素型やキー型がさらに複雑な型（ポインタやスライス等）である場合も再帰的に正しく表現する。
  • 現状の課題: derivingjson/generator.go 内で、この型文字列を手動で構築しようとしており、複雑で不完全になっている。

2. scanner.TypeInfo へのメソッド情報の集約

  • 目的: 型（特に構造体）が持つメソッドの一覧を TypeInfo 構造体内に直接保持するようにする。
  • 詳細:
    • scanner.Scanner が構造体をパースする際に、その構造体に紐づくメソッド（FunctionInfo で Receiver が設定されているもの）を収集し、TypeInfo.Methods []*FunctionInfo のようなフィールドに格納する。
  • 現状の課題: goscan.Implements 関数内で、構造体のメソッドを PackageInfo.Functions から毎回検索しており、効率と利便性の面で改善の余地がある。

3. 型解決ロジックの強化 (FieldType.Resolve())

  • 目的: FieldType.Resolve() がプリミティブ型や同一パッケージ内の型に対しても、より適切な情報（あるいは「解決不要」を示す明確なステータス）を返せるようにする。
  • 詳細:
    • プリミティブ型 (string, int 等) を識別した場合、専用のフラグや TypeInfo インスタンス（あるいは nil と特定のステータス）を返すようにする。
    • 同一パッケージ内の型を解決する場合、不要な外部パッケージ検索を行わないようにする。
  • 現状の課題: derivingjson/generator.go で Resolve() の結果を解釈する際に、警告が出たり、プリミティブ型の判定が煩雑になったりしている。

4. インターフェースの網羅的なメソッド解決（埋め込みインターフェース対応）

  • 目的: scanner.InterfaceInfo が、埋め込みインターフェースのメソッドも全て展開して保持するようにする。
  • 詳細:
    • scanner.Scanner.parseInterfaceType でインターフェースをパースする際、埋め込みインターフェースがあれば、そのインターフェースの定義を（必要であれば PackageResolver を通じて）解決し、メソッドを親インターフェースのメソッドリストに追加する。
    • メソッドの重複排除やオーバーライドのルールはGoの仕様に準拠する必要があるが、まずは単純なマージから実装する。
  • 現状の課題: 現在の parseInterfaceType は埋め込みインターフェースを検知するものの、そのメソッドを再帰的に展開していない。これにより goscan.Implements の精度が制限される可能性がある。

5. goscan.Implements の堅牢性向上

  • 目的: メソッドのシグネチャ比較をより厳密に行う。
  • 詳細:
    • compareFieldTypes で、型の完全修飾名（importパスを含む）を比較する。
    • 型エイリアスや、異なるパッケージにあるが実質的に同じ型などを考慮できるようにする（高度）。
    • スライスやマップの要素型なども再帰的に比較する。
  • 現状の課題: 現在の compareFieldTypes は型の名前とポインタの有無のみを比較しており、複雑なケースでは不十分。
    まずは現在の構文エラーの修正に集中しますが、これらのサブタスクについても進捗があり次第ご報告・ご相談させていただければと思います。
podhmopodhmo

2025-06-27

  • go-scanでjulesがパンクした
  • jules
podhmopodhmo

2025-06-28

  • go-scanで遊ぶ
  • 対話履歴の記録用のプロンプトを更新したい
podhmopodhmo

go-scanで遊ぶ

1つしかファイルを見ないのを複数のファイルを見られるようにした。

  • 先頭複数（最初に全部指定しなくちゃいけない）
  • importを辿る（どの方向へ？）
  • マーカー付きの型を探しそれの形状を辿る

ワンチャンあるパッケージの関数だけが呼べるインタプリタを作りその関数経由でimportを辿る。機能は決まってて対象を選ぶときだけ。

どういうものかを考えていた

https://github.com/podhmo/go-scan/blob/80126d9fa92746b9955d1a434499b830d5ea92fa/docs/ja/multi-project.md

podhmopodhmo

対話履歴の記録用のプロンプトを更新したい

そういう話をgrokとしてた。今は「思慮深い執筆者」
https://gist.github.com/podhmo/3cade1cf4a3366d964695160f34f1be3

読んだ。悪くない。追加したい。あとは対話に対話を重ねてる系のやつで試したい。

https://aistudio.google.com/app/prompts?state={"ids":["1rNr4nQ_RuVCPaXNM8kNCHJg8Jnj1USEZ"],"action":"open","userId":"108405443477417806091","resourceKeys":{}}&usp=sharing

もう少し試してみた。やっぱり過程をそのまま出力する系のほうが良いかな。

https://gist.github.com/podhmo/bb6116f077daf64d0787cbdf37780bd5

あとでプロンプトのコピー君に載せる

podhmopodhmo

そう言えば作家のai利用のやつ面白そうだった。後で真面目に読みたい。

ちょっとだけ見た。使い方がちょっと違うかも。aiを技術として認識してない感じだ。人として認識してる。あと一文一文が短い。

https://kohkoku.jp/case01/prompt/

podhmopodhmo

自分の対話はこんな感じ。

ユーザー入力履歴

ユーザー:
これは私とgrok（ai）との対話履歴です。あなたは2つのことをしてください。1つは対話内容をメタ的に捉え遷移を記述することです。もう1つはセカンドオピニオンとして対話の回答者になるということです。つまりgrokに対して検証したり助言をしたり懸念を表明したりしてください。

ユーザー:
なるほど。いくつか気になるポイントをコメントしますね。自己完結性は矛盾しないつもりです。簡潔さを求めてるのではなく意図しない借用を防ぎたいのです。それこそ対話を眺めなければ分からないような語の利用を（ちなみにaiが文脈を説明する情報を付与したり借用したりするのは構いません。あくまで対話の内容をその対話の存在を知ることなく確認できれば良いのです）。

あとgrokとの対話で気になった点といえば内省的が良いとは直接的には言ってないです。議論の中で話題に出てたと思いますが私の文章を分析させると内省的や思索的という言葉が出ますがそれをプロンプトに含めると私と乖離したテキストが出ることが多かったりします（これは内省的という表現が悪いという話ではなく考えを固定しないでくださいという補助的な言及です）。とは言えその逆の分析的で事実にしか基づかないみたいな方向の割り切りもビミョーに感じる時もあります。プロンプトを2つ用意するべきなのかもしれません。

ユーザー:
いいですね。あなたの提案する完全なプロンプトを教えてください。私の理解が正しければ3つ用意してくれるのですよね。

あ1つ補足すると記事が複数に分割された場合には続けますか？などと聞かず全部の記事を書ききってほしいです。

podhmopodhmo

2025-06-29

  • スマホからgistを見た時に折り返しをしたい
  • github pages上でcors突破できるかも？
  • 💭 7月になったらその3に以降するか。
podhmopodhmo

スマホからgistを見た時に折り返しをしたい

スマホでgistに載せたLLMとの対話履歴のmarkdown中でコードブロックの箇所が white-space: pre っぽいので全部を把握できないので辛い。折り返して表示して欲しい。

とりあえず、mobile firefoxからstylusを使うことにした。firefoxはブラウザ拡張がスマホ版でも入れられるのは便利。

テキトーにgrokにお願いしてcssを書いてもらった。

/* GitHub GistのMarkdownコードブロックに折り返しを適用 */
.markdown-body pre code {
    white-space: pre-wrap !important; /* コードを折り返す */
    word-break: break-word; /* 長い単語も適切に折り返す */
    overflow-x: auto; /* 必要に応じて横スクロールを維持（折り返し優先） */
}

/* コードブロック全体のスタイル調整（オプション） */
.markdown-body pre {
    overflow-x: hidden; /* 親要素の横スクロールを抑制 */
    padding: 10px; /* 読みやすさのためにパディングを調整 */
    line-height: 1.5; /* 行間を調整（必要に応じて） */
}
podhmopodhmo

emacsのフォント設定をする （WSL)

https://x.com/i/grok/share/rScxi2lT94o7BzB2DvOeFBJBT

現在のフォントの設定の確認

M-x describe-char

;; 漢字
;;  character: 設 (displayed as 設) (codepoint 35373, #o105055, #x8a2d) 
;;  ftcrhb:-GOOG-Noto Sans CJK KR-regular-normal-normal-*-15-*-*-*-*-0-iso10646-1 (#x9303)

;; ascii
;; character: s (displayed as s) (codepoint 115, #o163, #x73)
;; ftcrhb:-PfEd-DejaVu Sans Mono-regular-normal-normal-*-15-*-*-*-m-0-iso10646-1 (#x56)

今使えるフォントの一覧

$ fclist

windows側のフォントを設定できるようにする

/etc/fonts/local.conf

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <dir>/mnt/c/Windows/Fonts</dir>
</fontconfig>

cacheを更新する

$ sudo fc-cache -f -v
# /mnt/c/Windows/Fontsをみてくれている

$ fc-list | grep meiryo #

フォントの設定

(set-face-attribute 'default nil :family "Meiryo" :height 120)
(set-fontset-font t 'japanese-jisx0208 (font-spec :family "Meiryo"))

💭結局使わなかった

podhmopodhmo

toolchainはminor versionまで指定しないと駄目かも？

だるいね。

# ng
$  go install -v golang.org/dl/go1.24@latest
# ok
$  go install -v golang.org/dl/go1.24.4@latest

go: downloading go1.24 (linux/amd64)
go: download go1.24 for linux/amd64: toolchain not availabl