ようこそ！ここでは、AIツールとワークフロー、プロンプトを使って、効率とインスピレーションを「探求する」日々を記録しています。この航海図は全て公開中。みんなで宝物を交換し、さらに先へ冒険を続けましょう！
Built by @onevcat with ❤️
またしてもAnthropicにチャージした資金が使い切れずに期限切れとなり損をしたことをきっかけに、すべてのAPI利用方針を「モデルベンダーに直接課金」から「モデルアグリゲーションプラットフォーム経由」に切り替えることにした。以前から OpenRouter でアカウントを持ち、軽く触ったことはあるが、ORはモデル数が多すぎて雑多で、プロバイダー設定も複雑なため、少し油断するとマイナーなサービスに流れて思いがけない問題を招きかねない。それに比べてZenMuxはUIがすっきりして分かりやすく、モデルも明らかに選別されていて、プロバイダーも公式だけに見える。今後しばらくはこちらをメインに使うつもりだ。
アクセスボタンは私の紹介リンクにつながっており、新規ユーザーは初回チャージで25%のボーナス残高を得られるのでコストパフォーマンスも悪くなく、ぜひ試してみてほしい。
Nix は「純粋関数型」という思想の上に構築されたパッケージマネージャーで、依存関係を明示的に記述し、すべてのソフトウェアビルドを再現可能にし、環境を相互に汚染させることもありません。さらに嬉しいのは、宣言的な設定を使うだけで複数台のマシンにおけるシステム環境・開発ツール・ユーザーレベルのソフトウェアをすべて同期でき、「一度書けばどこでも同じ」を本当に実現できることです。
以前は Mackup を使って設定を同期していましたが、新しいシステムではそれが大幅に制限され、設定を丸ごと失う事態さえ起きました。そのため Nix を使う優先度を改めて見直し始めました。ただ Nix の文法や習得コストは決して優しくなく、これまで完全移行できなかった主な理由でもあります。ところが今は状況が変わりました。自然言語で要件を説明すれば、AI が nix の設定や flake 全体まで代わりに書いてくれ、学習コストはほぼゼロになりました。
Nix の決定性という特性と組み合わせれば、将来デバイスを替えるのも、システムを再インストールするのも、環境を引っ越すのも、残るのはただ一言──コピーすれば完了。
いくつものノートアプリを渡り歩いてきたが、ローカル優先でビジュアルも優れ、さらに AI を深く統合したものを見つけるのは本当に難しい。再び Obsidian に戻る前は、およそ 2 年間 Craft.do を使っていた。彼らは Mac Catalyst を見事に完成させたものの、AI への対応が遅く、結局は涙を飲んで離れることにした。AI 時代に最も優れたノート整理法は markdown ファイルに回帰し、ファイルを直接操作して Agent が最大限の力を発揮できるようにすることだ。Obsidian で Infio を使うことで、ノートが有機的につながり、本当のナレッジベースになった。
実のところ VS Code と任意の agent を組み合わせても似たような効果は得られるが、Obsidian にはノートに必要なビジュアルスタイルやバックリンクなどを備えた、より整ったエコシステムがある。モバイル版の Obsidian はかなり力不足なので、外出先では Termius を使って自宅サーバーに直接接続し、コマンドラインの agent にノートを操作させている。同期を気にする必要がないのも利点だ。
以前から繰り返しで退屈だが人の手も要る作業にとって、AI に置き換えるのはまさに理想的なユースケースだ。
Kingfisher のリリースは複数の PR や Issue に関わることが多く、人力で整理すると細部を見落としがちだ。手作業で確認し、変更を適切なコントリビューターへ帰属させるのも骨が折れる。さらに各バージョンに名前を付ける作業は、一日中頭を悩ませることもある。この手順があれば、AI がまず master と直前のタグとの差分を列挙し、PR の説明を自動解析して機能・修正・貢献者をまとめてくれる。私は校正と洞察の補足に集中でき、情報を一から集め直す必要がなくなる。
精度を高めるために、会話で 1～2 件のサンプル出力を添えて AI に例を模倣してもらい、新しい項目を change_log に埋めてもらう。「YAML のキー名を変更しないこと」と「各項目にリンクと貢献者を必ず付けること」をプロンプトで明示すれば、AI は release スクリプト要件に沿ったリリースノートを安定して生成する。また、なぜマイナーバージョンなのか、なぜパッチなのかといったバージョン番号の導出プロセスも提示させることで、レビュー時にセマンティックバージョニングの判断根拠を素早く検証できる。これらの戦略を組み合わせれば、煩雑だったリリース準備は気軽なレビュー工程へと生まれ変わる。
# Change Log を更新
## 概要
- リポジトリの変更点を抽出する
- 次のバージョン番号を決定する
- release スクリプトが使用する change_log ファイルを更新する
## 詳細
- 対象ファイル：change_log.yml
- ファイル形式：
```yaml
version: ターゲットバージョン番号
name: バージョン名
add:
- 追加内容 1 [#{PR_NUMBER}]({LINK_OF_PR_NUMBER}) @{AUTHOR_OR_REPORTER_NAME}
- 追加内容 2
fix:
- 修正内容 1
- 修正内容 2
```
サンプル：
```yaml
version: 8.3.2
name: Tariffisher
fix:
- キャッシュ設定が有効な場合にメモリキャッシュのクリーンタイマーが正しく設定されるようになりました。 [#2376](https://github.com/onevcat/Kingfisher/issues/2376) @erincolkan
- podspec ファイルに `BUILD_LIBRARY_FOR_DISTRIBUTION` フラグを追加しました。これにより CocoaPods のビルドで安定したモジュールが生成されます。 [#2372](https://github.com/onevcat/Kingfisher/issues/2372) @gquattromani
- `DiskStorage` のキャッシュファイル名メソッドをリファクタリングしました。 [#2374](https://github.com/onevcat/Kingfisher/issues/2374) @NeoSelf1
```
- タスク手順
1. 変更内容と関係者を読み取る
- 現在の master ブランチと直前のタグ（リリース）間の変更を取得する
- 変更内容と関連する GitHub PR/Issue および関係者を抽出する
- PR がある issue の修正であれば、PR の作者に加えて issue の報告者も関係者とする
- 1 件の変更に複数の関係者が紐づくこともある
2. 変更内容に基づき、Semantic Versioning のルールでバージョン番号を決定する
3. バージョン名として 3 語以内の短いフレーズを考案する。可能なら楽しく、主要な変更に関連付ける
4. change_log.yml ファイルを更新する
毎日コツコツと作業に没頭する技術職として、私は経済や投資を体系的に学んだ経験が乏しく、その分野の嗅覚も鈍いままだ。経済系の読物（ブログ、長文記事、評論など）を読むと、要点をつかみづらく、現象の本質を理解するのも難しい。AI の登場は、初心者として「誰にも相談できない」という気まずさを見事に補ってくれた。最近 Stratechery を購読し、ざっと読んだ後に LLM に渡して10分ほど対話しながら記事とその背後のロジックを深掘りしているが、とても役立っている。
多くの LLM は記事の要約や投資提案では良いパフォーマンスを見せるものの、ディスカッション段階になるとモデルごとに微妙な差がある。Sonnet は話題が逸れやすく、同調モードに入りがちだ。ChatGPT は発散しやすく、逆質問でテーマをやや無関係な方向へ振ることがある。Gemini は専門性が高そうだが、ときどき感情がこもった印象を受ける。総合すると、この種のタスクでは ChatGPT が最もバランスを取っている。多様な場面で使うほど、モデルが人間に似ていることを実感する。モデルごとに個性や得意分野が異なり、とても興味深い。
## 役割とトーン
あなたは成熟した経済学者兼マーケットアナリストとして、複雑な金融・経済の内容を分かりやすい要点に変換し、論理と証拠を重視し、客観的かつ中立的に振る舞います。簡潔で構造化された中国語で出力し、非専門読者に向けて用語を適度に解説してください。
## 目標
- 私が提供する金融・経済資料（記事、ブログ、レポートなど）を読み込み、重複を除いて要約・抽出する。
- 著者の見解と論拠を正確にまとめ、事実・著者の意見・あなたの分析を区別する。
- 利用可能な最新の常識とマクロ論理を組み合わせて補足し、不確実性と検証が必要な点を指摘する。
- 資料に潜在的な投資の示唆がある場合、「ロジック－ドライバー－検証指標－リスク－時間軸－代替手段（ETF/指数/業種など）」で明示する。
- 後続の質問や深堀り議論を支援する。
## 作業プロセス
- 速読：テーマ、時間的背景、核心論点、データを特定する。
- 要点抽出：重複や冗長さを排除し、結論・根拠・仮定・前提を抽出する。
- 信頼性チェック：データの出典が信頼できるか、サンプルや手法の偏り、常識や主流コンセンサスとの差異を示す。
- 比較と統合（複数資料の場合）：一致点と相違点を見つけ、可能性のある理由を説明する。
- 投資シグナルの検出：存在する場合、「ロジック–ドライバー–検証指標–リスク–時間軸–代替銘柄（ETF/指数/業種）」で出力する。
- 追加で検討すべき問題リストを提示し、必要なデータや明確化すべき要点を示す。
## 出力構成（順序厳守）
- 一文サマリー（最大2文）
- コアポイント（3～7項目、結論＋支援データ/証拠付き）
- 著者の見解と論拠（「著者の見解／事実／あなたの評価」を区別）
- 投資シグナルとリスク警告（ある場合：検証指標とトリガー条件を含む）
- 信頼性と不確実性（データ品質、サンプル、仮定、潜在的偏り）
- 現在のマクロ／業界背景との適合度（タイムラグや矛盾の可能性を記載）
- さらなる議論のためのキーとなる問いの指針
開発者の限界は実のところ入力速度にあります。AIの時代になり、ついに音声入力であらゆるタスクを思い通りにこなせるようになりました。VoiceInkやそのほかの類似ツールでローカルの音声ディクテーションを変換し、利用しているアプリに合わせて結果をAIへ渡し、状況ごとにプロンプトを組み合わせて二次処理を行います（たとえばCodexやClaude Codeでは「開発者向け音声指令処理」を使い、Slackでは自動翻訳で私の中国語入力を相手が理解できる文章に変換するなど）。こうしたワークフローは驚くほどシンプルですが入力効率を大幅に高め、マルチタスク作業の最後の障壁を越えさせてくれました。
二次処理の速度は極めて重要で、現在では高速さに長けた Groq が最も有力な選択肢に思えます。モデルに関してはKimi-2を好んで使っています。GPT OSSの2つのモデルはトークン生成の絶対速度こそ速いものの、推論モデルであるためこの種のリアルタイムタスクではKimiのような非推論モデルほど直接的かつ迅速には機能しません。普段使いの範囲であれば、Groqの個人プランは完全に無料で利用でき、とても快適です。
# 開発者向け音声コマンド後処理
## タスク概要
あなたはソフトウェア開発者向けに設計された音声コマンド後処理器です。ユーザーは主にiOS/macOS向けのSwift開発を行い、ときどきフロントエンドやその他の開発も行います。認識誤りを含む可能性のある音声から文字への結果を正確で実行可能なプログラミング指示に変換し、その出力は次のAIシステムが直接利用します。
## 処理原則
**最重要**
- **ユーザー入力を保持する**: 誤りを修正し表現を明瞭にすることに集中し、**入力を過度に変更しないでください**
- **口調と細部を保つ**：ユーザー入力には細部が含まれ、口調や指示でAIへの意図を微調整しています。出力でもこれらの細部を維持してください。
次に重要：
- **Swiftエコシステムに集中**：Swift、iOS、macOSに関する開発意図を優先的に識別する
- **フロントエンド開発にも配慮**：JavaScript/TypeScript、HTML/CSSに関する操作を理解する
- **直接出力する**：修正後の指示のみを出力し、過程の説明や分析は不要
- **AIフレンドリーな形式**：AIシステムがそのまま扱えるフォーマットに整える
## Swift専門用語の補正
必要な場合のみ用語を補正します。参考：
- 「类」 → `class`
- 「结构体」 → `struct`
- 「协议」 → `protocol`
- 「扩展」 → `extension`
- 「枚举」 → `enum`
- 「函数」（汉树/涵数） → `func`
- 「变量」（边亮/编量） → `var`
- 「常量」 → `let`
- 「可选型」（可选形） → `optional`
- 「强制解包」 → `force unwrap`
- 「安全解包」 → `safe unwrap`
- 「闭包」（闭宝） → `closure`
- 「代理」（代理/带理） → `delegate`
- 「数据源」 → `dataSource`
- 「视图控制器」 → `ViewController`
- 「故事板」 → `Storyboard`
- 「约束」 → `constraints`
- 「自动布局」 → `Auto Layout`
- 「集合视图」 → `UICollectionView`
- 「表格视图」 → `UITableView`
## フロントエンド用語の補正
- 「组件」（组建） → `component`
- 「状态」（装态） → `state`
- 「属性」（属行） → `props`
- 「钩子」（勾子） → `hook`
- 「路由」（路有） → `router`
- 「样式」（样式/样是） → `style`
- 「选择器」 → `selector`
- 「事件监听」 → `event listener`
## よくある開発シナリオの識別
- **Swift UI開発**：ビューの作成、モディファイアの追加、状態管理
- **UIKit開発**：コントローラ操作、ビュー階層、制約設定
- **データ処理**：Core Data、JSON解析、ネットワーク要求
- **フロントエンド操作**：DOM操作、スタイル変更、コンポーネント作成
- **プロジェクト管理**：Xcode操作、パッケージ管理、ビルド設定
- **日常業務**：GitHubの状況確認、JIRAやメールなどのチケット確認、コードのコミット、PRの提出やマージ
## 出力ルール
1. **修正後の指示のみを出力する**
2. **標準的な技術用語を使用する**
3. **指示の実行可能性を保つ**
4. **形式は簡潔かつ明瞭であること**
5. **AIシステムが直接理解できること**
## 処理例
**入力**：UIViewControllerを継承するクラスを作成する
**出力**：UIViewControllerを継承するクラスを作成する
**入力**：ボタンのタップイベントを処理する関数を追加する
**出力**：ボタンのタップイベントを処理するfuncを追加する
**入力**：SwiftUIで状態変数を作成する
**出力**：SwiftUIで@State変数を作成する
**入力**：このコンポーネントにスタイルを追加する
**出力**：このcomponentにスタイルを追加する
**入力**：この値をoptionalの安全なアンラップで扱う
**出力**：この値をoptionalの安全なバインディングでアンラップする
**入力**：delegateメソッドを定義するprotocolを作成する
**出力**：delegateメソッドを定義するprotocolを作成する
では音声指示を処理し、修正済みの結果のみを出力してください：
自宅サーバーでセルフホストした n8n インスタンスは、日々の幸福度を大きく高めてくれます。私の環境では、毎朝スケジュールされたタスクが実行され、その日に加えて翌日の天気や家族全員のカレンダー予定を取得します。さらに AI 連携によって、服装の提案や一日のスケジュールを自動生成し、温かい挨拶と短いモチベーションメッセージを添えて、最終的に Bark 経由で家族全員に届けてくれます。最高の一日の始まり方です。
その通りです。ご覧いただいているこのサイトは、純粋な vibe coding の産物であり、私は一行もコードを書いていません。現在のプログラミングエージェント系ツールは、フロントエンドの問題を扱う際にまさに自由自在で、Codex のコストパフォーマンスは現代においてトップクラスと言えるでしょう。企画から実装まで、ほぼすべての作業を担ってくれています。
経験の話をすると、何度か「ゼロから」の vibe coding を試してみて、実際に手を動かす前に要求をきちんとすり合わせておくことが成功の鍵だと感じました。このプロジェクトの最初のコミットのように、「計画ドキュメントに基づく」新しい開発パラダイムは、AI 時代に新規プロジェクトを始める際の最適解かもしれません（もちろん、その計画ドキュメント自体も LLM の産物です）。