メインコンテンツへスキップ

Codex

開発日誌 2026-08-15 — タスク監視パネルの正式リリースと表示改善

·51 文字·1 分
今日やったこと # タスク監視パネルを正式リリース # 実施内容: タスク、子エージェント、選択中の会話容量、週次の利用可能量を一つのローカル画面で確認できる構成を正式版としてまとめた。 結果: 実行状態、要確認、固定表示、親子関係に加え、モデル、推論強度、残りの会話容量を表示できるようにした。利用状況は消費量より残量を前面に出した。 安全設計: 通信先を利用端末内に限定し、タスク名や作業名を外部へ送らない方針を維持した。根拠のない完了率も表示しない。 未完了: 実験的な接続方式に依存しているため、接続先の仕様変更への追従は継続課題として残った。 検索とレスポンシブ表示を改善 # 実施内容: タスク名、作業名、モデル、推論強度による検索と、優先度、更新時刻、作業名による並べ替えを追加した。 結果: 表示条件、検索語、並べ替え、子エージェントの開閉状態を再読み込み後も保持できるようにした。 表示改善: 横幅がある画面では利用状況を細い帯へまとめ、タスクを複数列で一覧できるようにした。720ピクセル未満では一列へ戻す構成に調整した。 タスクカードの密度と優先順を調整 # 実施内容: タスクカードを個別または一括で最小化し、子エージェントの総数、実行中、要確認を短い要約で残せるようにした。 結果: 多数のタスクを俯瞰しながら、必要なカードだけを展開できるようになった。 問題と修正: 複数列表示に段組みを使うと優先順が縦方向に流れたため、格子状の配置へ変更し、優先度の高いタスクが行方向に並ぶよう修正した。 前日分の公開日誌を反映 # 実施内容: 前日分の開発日誌を新規公開し、タスク可視化、レビュー収集、個人PCの定期処理に関する作業を記録した。 結果: 対象記事だけを追加し、開発以外の操作性改善や個人環境向け作業も日次記録へ含めた。 判断と学び # 利用状況は消費量より残量を示した方が、次の作業を始められるか判断しやすい。 タスクが増える画面では、情報を削るのではなく、最小表示と展開を利用者が切り替えられる方が俯瞰性と詳細確認を両立しやすい。 CSSの段組みは省スペースだが、優先順を保ちたい一覧には格子状の配置が適している。 安全策はローカル通信、外部公開の防止、推測表示の禁止のように、守る境界ごとに実装すると確認しやすい。 検証 # 対象時間帯の活動として、監視パネルの6件のリリースコミットと、前日分日誌を追加した1件のコミットを確認した。 最新版には、サーバー側の構文検査と自己検査、画面側の構文および主要表示要件を確認する検査手順が定義されていることを確認した。 各リリースで検査条件も更新されていたが、リモートの自動検査結果は記録されていなかったため、通過済みとは扱わなかった。 公開文面は固有の作業場所、識別子、連絡先、秘密情報、リポジトリ情報を含まないことを検査した。 次にやること # リモートの自動検査を追加し、構文検査、自己検査、主要な画面要件をコミットごとに確認できるようにする。 タスク数が多い状態と狭い画面で、検索、最小表示、優先順が意図どおり維持されるか継続確認する。 実験的な接続方式の変更を監視し、利用状況やタスク状態の取得失敗を明確に表示する。

開発日誌 2026-08-14 — タスク可視化、レビュー収集、定期処理の改善

·48 文字·1 分
今日やったこと # タスク可視化パネルを公開可能な形に整理 # 実施内容: Codexのタスクとサブエージェントの状態を、細いサイドパネルやブラウザで確認できるローカルダッシュボードとしてまとめた。 結果: 実行中、要確認、待機中を分け、親子関係、更新時刻、承認待ちを3秒間隔で表示する初期実装を整えた。通信先はローカルに限定し、根拠のない完了率は表示しない設計にした。 判断: 当初はパッケージ管理ツール全般を禁止したが、配布と利用まで不必要に狭めると分かった。ローカル利用は許可し、公開レジストリへの誤公開だけを設定で防ぐ方針へ修正した。 未完了: 公開用の初期構成までは整えたが、当日中の正式リリースと継続的な自動検査は未完了だった。 レビュー収集PWAの入力体験を改善 # 実施内容: 文字、音声、写真を一まとまりにし、1回の操作で登録できるようにした。写真の添付中は下書きとして保持し、完了後に処理へ進める流れに変更した。 問題と修正: 写真送信に失敗した場合はブラウザ側の未送信状態を片付け、保存済みレビューの編集画面から再登録できるようにした。写真だけのリセットと入力全体のリセットも追加した。 結果: 利用者が添付した写真を自動取得した表紙より優先し、レビュー画面からサムネイルを切り替えられるようにした。公開画面からは不要な中間項目を外した。 未完了: 稼働環境への反映と動作確認までは完了したが、変更提案は下書きのまま未マージだった。 Windowsの定期処理を目立たず動かすよう修正 # 実施内容: 個人PCで動く同期処理とバックアップ処理の起動設定へ、PowerShellのウィンドウを非表示にする指定を加えた。 結果: 定期実行のたびに画面へウィンドウが現れる問題を、2種類の登録処理で同じ方針にそろえて修正した。 未完了: 設定差分は反映したが、実機での連続実行結果は当日の記録から確認できなかった。 判断と学び # 安全策は利用経路を一律に禁止するより、実際に避けたい操作へ絞って強制する方が運用しやすい。 状態監視では推測した進捗率より、実行中、入力待ち、異常といった確認可能な状態をそのまま見せる方が信頼できる。 写真を含む入力では、送信単位、下書き保持、失敗後の再登録を一つの流れとして設計する必要がある。 個人PC向けの小さな改善でも、同期とバックアップのような反復処理では日常の割り込みを大きく減らせる。 検証 # レビュー収集PWAは自動テスト36件、静的検査、ブラウザ用スクリプトの構文検査を通過した。 モバイル幅で統合送信、2種類のリセット、写真2枚のサムネイル切り替え、公開画面を確認し、ブラウザコンソールのエラーがないことを確認した。 稼働環境のヘルスチェック、Web処理、定期処理、起動ログに異常がないことを確認した。 タスク可視化パネルには構文検査と自己検査の手順を用意したが、当日分のリモート自動検査記録はなかった。 公開文面は固有の作業場所や識別子を一般化し、公開禁止情報を含まないことを検査した。 次にやること # タスク可視化パネルの正式リリースと自動検査を整え、実際のタスク状態との一致を継続確認する。 レビュー収集PWAの変更提案を最終確認し、下書き状態を解消して統合する。 Windowsの同期処理とバックアップ処理を実機で繰り返し動かし、ウィンドウが表示されないことと処理結果を確認する。

開発日誌 2026-08-13 — 日次公開の自動化、システム可視化、利用傾向分析

·87 文字·1 分
今日やったこと # 日次日誌をPC非依存化 # 実施内容: 公開日誌の生成を常時稼働環境のCodexへ移し、GitHub Actionsを予備経路にした。 結果: 毎日決まった時刻に公開でき、主経路が失敗した場合も後続処理で補完できる構成にした。 検証: スモーク実行で対象日の記事更新、公開安全性検査、リモート内容の一致を確認した。 音声通知の取りこぼしを修正 # 実施内容: セッションイベントを直接監視し、選択肢表示と処理完了を別々の音声で通知するようにした。 問題と修正: ポーリング中心の監視で見逃す余地があったため、イベント駆動へ切り替え、音声合成エンジンを事前起動した。 結果: 応答待ちと完了の状態を短い音声で判別できるようになった。 検証: 代表的なイベント列を使った回帰確認を通した。 低予算向けベンチマークを設計 # 実施内容: AIエージェントを公平に比較するため、課題、採点、実行記録、公開結果を分離した枠組みを整えた。 結果: 模擬候補によるスモーク6項目とlaunch検証は通過した。 問題と修正: 実モデルでは候補シェルのOSレベル通信隔離が未証明で、凍結依存のライセンス欠落と存在しない検証成果物の要求も見つかったため、モデル実行前に失敗側で停止した。 判断: 隔離、凍結依存、要求成果物を整合させるまで実モデルを起動せず、費用を発生させない方針を維持した。 GitHub共同作業実績を安全に試行 # 実施内容: 自分で管理する公開検証環境を使い、質問への有効回答と承認、共同コミットの流れを確認した。 結果: 回答採用に関する実績を2段階まで確認し、共同コミットに関する達成条件も満たした。 問題と修正: 共同コミット用の一時的な書き込み経路は、マージ完了後に既定ブランチと作業ブランチの両方から削除した。 検証: 共同作者として認識されることを確認したが、プロフィール上の実績表示は外部側の判定待ちとして未達扱いを続けた。 個人システム全体のトリガーを可視化 # 実施内容: 常時稼働環境、ローカル環境、Codex、GitHub Actions、ブログ、LLM Wikiの役割と起動経路を1枚の概要へ統合した。 成果物: 3種類の構成図、6種類のトリガー分類、正本、再監査手順をまとめた。 結果: 失敗中の定期処理、古いタスク、Wikiの差分、日誌生成の重複、書き込み役不在の監視処理を課題として特定した。 実施内容: 非公開Wikiのリモート更新38件と競合2件を統合し、30分ごとに安全な状態だけを同期する定期処理を導入した。 問題と修正: 診断記録の置換処理と実行環境の選択で初回エラーが出たため、記録方式を単純化し、利用可能な環境を1件だけ選ぶよう修正した。作業中にリモートが進んだ場合は自動送信を停止し、統合後に再開した。 検証: Wikiの検査、既存19テスト、秘密情報検査、実際の自動送信、2回目の変更なし終了を確認した。未追跡の個人記録は同期対象から除外した。 Codex利用傾向と料金構成を比較 # 実施内容: 直近1か月の利用日数、メインタスク数、サブエージェント数、モデル比率、推論強度、週次上限の到達状況を集計した。 結果: 23日利用、64件のメインタスク、263件のサブエージェントという高負荷な使い方で、上位モデルと高推論の比率も高かった。 判断: 低価格な従量枠への移行は容量不足になるため、現在の大容量プランを維持する結論にした。 実施内容: 同価格帯の別サービスも比較し、モデル性能、並列エージェント、作業領域、検索能力は有力だが、具体的な週次上限が非公開であることを確認した。 判断: すぐに切り替えず、無料の実行環境で大型タスクと並列作業を試し、ピーク週の実効容量を確認してから判断することにした。 判断と学び # 自動化は主経路と予備経路を分け、同じ成果物を重複生成しない責務分担が重要だ。 実行基盤の安全性を証明できない場合は、便利さより失敗側で止まる設計を優先する。 システム全体の入口、正本、書き込み権限を1枚で見える化すると、個別障害より先に構造的な重複や欠落を発見できる。 料金比較は月額やモデル性能だけでなく、実際の並列度、推論強度、週次上限まで含めて判断する必要がある。 外部サービスの達成条件と表示反映は別の状態として扱い、判定待ちに追加操作を重ねない。 検証 # 公開記事から認証情報、非公開リポジトリ識別子、ローカル絶対パス、タスク識別子、未公開コミット識別子、URLを除外した。 完了を確認できた成果と、未解決または継続確認中の事項を分けて記載した。 日誌自動化、音声通知、Wiki、スキルについて、それぞれの回帰確認または静的検査結果を確認した。 次にやること # 通信遮断、凍結依存、要求成果物を整合させ、ベンチマークの実モデルスモークを通す。 自動同期の定期動作を監視し、残る古いタスクと重複書き込みを優先順に解消する。 共同コミット実績はプロフィール表示を確認するまで未達として扱う。 別サービスは無料環境で実効容量を計測してから、現在の大容量プランとの再比較を行う。

開発日誌 2026-08-12 — 工学ベンチマーク検証と技術・市場調査

·58 文字·1 分
今日やったこと # 工学ベンチマーク基盤を実モデルで検証 # 実施内容: 既存の段階式プロトコルを再利用し、合成E2Eの後に2種類の実モデルで非公式smokeを実行した。 結果: 一方は17分25秒で最終チェックポイントまで完了し、もう一方は20分の時間上限に達して部分提出となった。 検証: STEP 3件の再読込、統合、匿名化、レビュー包生成まで確認した。総合チェックは136件成功、失敗0件、環境依存のスキップ1件だった。 判断: 基盤は条件付き合格とした。独立レビュー、正式反復、公開はまだ行わず、残る2点の修正を先に進める。 Codexの応答スタイルを調整 # 実施内容: 個人向けの共通指示へ、明るい口調と絵文字を使う方針を追加した。 結果: 共通指示の行数制約内に収め、新しく開始するタスクから同じ会話スタイルが適用される状態にした。 Neural Operatorによる熱解析の調査を公開 # 実施内容: 3D-ICの温度場を推定する代理モデルの論文を読み、FNO、U-Net、自己注意、転移学習の役割を整理した。 判断: 推論時間の約842倍という比較は、学習、前処理、再解析、独立検証を含む工程全体の短縮率ではないと切り分けた。 結果: 材料・航空宇宙CAEへの展開では、平均誤差だけでなく、最大温度や勾配、分布外検出、再解析条件、データ来歴を導入ゲートにする方針をまとめた。 成果物: 技術調査記事の作成と公開まで完了した。 市場データを整理して夕方レポートを公開 # 実施内容: 国内主要指数、為替、海外市場、政策・企業開示を複数の公開情報で照合した。 判断: 指数上昇と個別銘柄の広がりを分け、発表前の市場予想と確定済みの実績を混同しない構成にした。 成果物: 市場レポートの作成と公開まで完了した。 判断と学び # 実モデルsmokeでは、正常完走だけでなく、時間超過や矛盾した記録を安全に拒否できることも重要な検証になる。 自動評価で物理性能を断定できない項目は、無理に合格へ寄せず不確実として止める。 代理モデルの速度倍率は、学習と検証を含む総工程へ換算し直さなければ導入判断に使えない。 市場調査では、確認済みの数値、発表前の予想、値動きの解釈を分離すると、断定のし過ぎを避けられる。 日常設定は毎回のプロンプトへ書かず、共通指示へ最小限だけ置くと運用しやすい。 検証 # 実モデル成果物のCAD再読込と決定論的検査を完了した。 レビュー未提出時に処理が停止することを確認した。 共通指示の行数制約内で応答スタイルの追加を確認した。 技術調査では、論文中の精度指標、時間比較、データ件数の表記を突き合わせ、比較範囲と不整合を明記した。 市場調査では、指数、為替、企業開示の時点と出典を照合した。 次にやること # レビュー未提出時のエラーを説明的な表示へ直す。 表示用メッシュを生成できるSTEPを提出要件にするか、評価境界を統一する。 独立レビュー後に、正式反復へ進めるか判断する。 代理モデル評価では、分布外検出と高忠実度解析へ戻す条件を具体的な試験項目へ落とす。

開発日誌 2026-08-09 — 知識基盤の可搬化と個人システムの改善

·75 文字·1 分
8月9日は、知識基盤の可搬化と、日常的に使う個人システムの改善を進めた。 今日やったこと # 個人LLM Wikiを可搬化 # 実施内容: 個人LLM Wikiと日次登録タスクを、別環境へ移せる非公開の移行パッケージにまとめた。 安全対策: 実行場所に依存しない参照へ揃え、資格情報、生の会話履歴、個人用同期設定は含めない構成にした。 結果: 新規取得した環境からも検査できることを確認した。 作品感想サイトの入力経路を統合 # 実施内容: 音声、テキスト、写真の入力を一つの流れに統合し、ローカルWhisperで文字起こし、Codex CLIで構造化する構成にした。 改善内容: 認証状態、画像表示、スマートフォン向け操作、失効できる公開共有、Obsidianへのミラーを整えた。 再処理: 人が文字起こしを直した後は、音声認識をやり直さず、修正版テキストだけをLLMへ再投入できるようにした。 Codexの状態を音声通知 # 実施内容: 公式の通知フックからローカルのVOICEVOXへ渡し、春日部つむぎの音声で案件名と結果を知らせる形にした。 動作設計: 音声合成は非同期で動かし、エンジンの自動起動と固定音声へのフォールバックを用意した。 通知内容: 完了、承認待ち、失敗で読み上げ内容を変えた。 感想記録向けLLMサービスを比較 # 比較対象: OpenAI、GroqCloud、Together AI、OpenRouter、DeepInfraを比較した。 運用方針: 通常はローカルWhisperと低コストの構造化処理を使い、信頼度が低い場合や出力形式が崩れた場合だけ、検索または高性能モデルへ段階的に上げる。 開発日誌の自動化を整理 # 実施内容: Codexのタスク履歴とGitHub上の正本だけで動くようにし、開発PCに依存しない構成にした。 処理経路: 非公開Wikiへ知識を統合した後、公開安全化した一日分の日誌を作る一方向の流れにした。 対象範囲: 過去8日分を補完し、開発だけでなく、デザイン、文書、調査、比較、相談、個人環境の作業も記録対象に含めた。 循環防止: 公開日誌そのものはWikiへ戻さない。 サブスクリプションを整理 # 役割分担: 受信箱から候補を見つける役割と、実際の請求を確認する役割を分けた。 確認方法: ChatGPT Workを候補収集、Codexを整理と判断支援に使い、カード、銀行、アプリストアの記録で事実を確認する。 結果: 1件の解約を完了し、終了日、最終請求、契約一覧から消えたことまで確認した。 判断と学び # 可搬性は、取得先を基準に動き、秘密情報を外へ出さず、新しい環境で検証できることまで含む。 非公開知識と公開日誌は、一方向の安全化変換にすると、情報漏えいと再取り込みの循環を避けやすい。 LLMサービスは単価だけで選ばず、音声認識、検索、構造化出力、失敗時の再試行まで含めて比較する。 非同期処理では原入力を先に保存し、処理失敗後も再実行できるようにする。校正済みテキストは音声認識を省略して再利用する。 継続課金は、候補一覧ではなく請求記録と契約状態で確認する。 検証 # 知識基盤は新しい取得環境で297ノートの検査、既存19テスト、可搬パス検査を通した。 感想記録サイトは36テストを通し、モバイル表示、稼働状態、認証、共有リンクの作成から無効化までを確認した。 音声通知は完了、承認待ち、失敗、エンジン再起動、フォールバックを実機確認した。 日次公開は過去分の補完、公開前の機密検査、公開後の内容照合まで確認した。 次にやること # 個人用同期先への反映は、人が新しい索引と記事ノートを確認した後に行う。 感想記録は実データでモデルごとの精度、待ち時間、費用を同じ条件で比較する。 実機のスマートフォンで長めの録音と写真付き記録を試す。 サブスクリプション候補を請求記録と照合し、不要な契約だけを明示確認後に整理する。

開発日誌 2026-08-08 — 第二の脳・作品DB・お品書き制作

·83 文字·1 分
8月8日は、知識基盤と作品データベースの整備、Codex運用の整理、イベント向けお品書きのデザインを進めた。 今日やったこと # 第二の脳を実運用へ移行 # 実施内容: Obsidianを読む入口、Markdownを長期保存形式、Codexを継続的な編纂役とする知識基盤を実用状態まで進めた。 設計: 端末間で共有する領域と、原典・秘密情報・ツール設定を置くローカル領域を分離した。 安全対策: クラウド同期は許可リストだけに限定し、初回同期の前後にdry-runで追加・取得・削除・競合を検査した。 結果: 通常ファイル20件とディレクトリ18件を全件照合し、内容差分、欠落、許可範囲外のファイルがないことを確認した。 バックアップ: 変更時だけ検証済みバックアップを作る日次タスクを追加し、復元試験まで通した。 作品と感想を一か所へ集約 # 実施内容: 電子書籍のハイライト取込を、映画、ゲーム、音楽、動画、ガジェットなども扱える作品データベースへ拡張した。 設計: 安定した「作品」と体験ごとの「感想」を分け、自動生成データと手書き本文も別領域にした。 構成: Obsidian標準のProperties、Bases、Templatesだけで、作品一覧、感想一覧、登録テンプレート、横断ダッシュボードを構成した。 結果: 677作品、3,167件のハイライト、677枚の表紙を統合した。 問題と修正: Windowsへの取得で日本語ファイル名が文字化けしたため、個別ファイル指定をやめ、サーバー側のアーカイブを受け取る方式へ変更した。 移行結果: VPS側を新しいデータ構造へ移し、作品ノートと索引をまとめて同期できた。 Codexの日常操作を短縮 # 実施内容: 個人用の共通指示を必須項目だけに絞り、詳細な委譲ルールを別文書へ分離した。 操作方法: 通常は自動判断し、必要なときだけ短い言葉でサブエージェント利用、並列実行、単独実行を切り替えられるようにした。 モデル設定: メイン役と子エージェントのモデル・推論強度を役割ごとに固定し、難しい問題だけ高い推論設定を選ぶ構成にした。 C108のお品書きを制作 # 実施内容: SNSとブログ向けのお品書きを、既存の表紙・ロゴ素材から組み立てた。 反復修正: 日付と曜日の強調、ロゴ周辺の透過、表紙と説明枠の高さ、価格と仕様の重なり、既刊カードの透過感を順に調整した。 組版: Affinity Designer 2へ移し、筑紫明朝、筑紫オールド明朝、筑紫ゴシックで再構成した。テキストは編集可能な状態を保ち、ロゴを130%へ拡大して視覚中心を整えた。 簡素化: 読みにくかった短いコード表記を、白文字、濃紺の薄い影、金の縦罫だけへ整理した。 成果物: 編集用データ、PNG、素材参照版と画像埋め込み版のSVGを保存した。PNGは1086×1448ピクセル、sRGB、ICC埋め込みを確認した。 公開方針: AIはレイアウト検討と修正補助に使い、最終デザインと組版はデスクトップの組版ソフトと正規ライセンスのフォントで仕上げた。公開時は「生成AIを制作工程の一部に取り入れています」と表現する。 個人知識を集める入口を整理 # 方針: 「自分の判断と理由」「何度も説明している知識」「失敗・気づき・うまくいったパターン」の3種類を優先する。 目的: 日記を量産せず、将来の判断や行動に再利用できる形を先に作る。 運用: 週に5〜10件のメールやブログを選び、原典を残したまま判断・知識・教訓へ分類する小さな流れから始める。 判断と学び # 同期成功とバックアップ成功は別物として扱う。同期、Git履歴、検証済みアーカイブを独立させると戻しやすい。 自動生成データと人が育てる文章は保存領域を分ける。 dry-runは許可範囲外の操作が1件でもあれば止める安全ゲートにする。 日本語ファイル名を複数のシェルへ渡すより、アーカイブ単位の受け渡しが文字コード差に強い。 エージェント運用は設定項目を増やすより、普段の言葉を少数の操作へ対応づける。 デザインは要素を足すより、視線の順序と文字の役割を決め、不要な装飾を外す。 AI利用は、AIの担当範囲と人が仕上げた工程を分けて説明する。 検証 # 知識基盤はlint、19件の回帰テスト、クラウド側との全件ハッシュ照合、バックアップ復元を確認した。 作品データベースは18件のコードテストと、知識基盤側の19件+5サブテストを通した。 Codex設定は通常・難問・子エージェントの各経路を設定診断で確認した。 お品書きは各稿の目視・数値検証、Affinity Designer 2での再保存、PNG書き出し、色空間、編集可能性を確認した。 資格情報、認証Cookie、秘密鍵、非公開リポジトリのアドレスは掲載していない。

開発日誌 2026-08-07 — Codexのモデル・通知・GUIを整備

·51 文字·1 分
8月7日は、個人開発で毎日触るCodex周辺の操作を短くし、完了や入力待ちを腕時計で追えるようにした。 今日やったこと # モデル経路を役割ごとに固定 # 実施内容: 日常的な実装はSol xhigh、高度な計画やレビューはSol max、サブエージェントはLuna maxを使う構成にした。 結果: SolとLunaは実際の応答と子セッション記録で確認した。 運用方針: 外部モデル向け接続プロファイルは用意したが、ローカル実行基盤やAPI設定がないものは有効化していない。 共通指示: 過剰な抽象化や将来用の仕組みを避け、実際のデータ消失や秘密情報の境界を守る方針を加えた。 Pebble通知を状態遷移へ結び直す # 問題: Codexの進捗イベントが出るたび通知されていた。 修正: 入力・承認待ち、完了、失敗だけを通知対象とし、定期的な進捗報告は抑止した。 表示: タイトルにモデル名・推論強度・状態、本文にタスク名を置く短い形式にした。タスク名を取得できない場合だけフォルダ名へ戻す。 追加修正: 再インストールでフック位置と信頼済みハッシュが変わる問題を見つけ、既存位置を維持するようインストーラーを修正した。 結果: 届かなかった完了通知を再送した。 T3 Codeから同じプロジェクトを利用 # 実施内容: T3 Codeを導入し、GitHub認証とCodex認証を確認した。 結果: Codexと共通のプロジェクト領域を開き、試用リポジトリのREADMEをCodexに読ませるところまで通した。 変更範囲: ファイルは変更せず、新しいリポジトリの公開も行っていない。 判断と学び # 通知はツール呼出しではなく、利用者が行動する必要のある状態遷移へ結び付ける。 再インストール可能なフックは、内容だけでなく配置場所の安定性も契約になる。 モデル選択は毎回の細かな指定ではなく、日常用と難問用の少数プロファイルへまとめる。 複数GUIで同じリポジトリを使う場合、認証、作業領域、公開権限を分けて確認する。 検証 # 通知まわりの38件のテストを通した。 日常用、難問用、子エージェントのモデル経路を診断した。 T3 CodeのGitHub認証、Codex実行、読み取り専用の試用を確認した。 資格情報、認証Cookie、非公開リポジトリのアドレス、個人PCのパスは掲載していない。

開発日誌 2026-08-06 — Orcaで開発環境を横断

·37 文字·1 分
8月6日は、Codex以外のエージェントも選べるOrcaを、既存の個人開発環境へ接続した。 今日やったこと # 共通の作業領域と安全な既定値を整備 # 実施内容: Orcaを導入し、Codexと同じプロジェクト群を開ける作業領域、PowerShell、既存のGitHub認証とSSH設定を引き継いだ。 安全設定: 既定エージェントはCodexとし、承認やサンドボックスを迂回する全権限モードは無効化した。 結果: Codex、Claude、Gemini、OpenCodeのCLIを認識できる状態にした。Codexは実働を確認し、利用者ログインが必要なサービスは導入だけに留めた。 非公開リポジトリで開発経路を確認 # 実施内容: Orca管理のworktreeで、外部依存のない小さなHTTPアプリを作成した。 結果: 実装、テスト、コミット、非公開リポジトリへの反映までを一つの作業経路で通した。 VPSへの軽微な反映を確認 # 実施内容: 既存SSH設定でVPSへ接続し、専用領域へ4ファイルを転送した。 問題と修正: VPSにNode.jsがなかったため追加インストールせず、Pythonの一時HTTPサーバーを使った。 結果: ローカル応答200を確認し、確認後はサーバーを停止して一時実行ファイルも削除した。 変更範囲: sudo、パッケージ、Firewall、常駐サービスは変更していない。 判断と学び # PowerShellでは、検索結果が1件だけだと配列ではなく単一の文字列になることがある。結果を明示的に配列化し、SSH接続先の誤判定を解消した。 開発ツールを増やす場合も、認証情報を複製するより、既存の認証と標準CLIを再利用する方が運用しやすい。 検証 # Orcaのランタイムとオーケストレーションを確認した。 Codexの実行とGitHubへの反映を確認した。 VPS接続、ファイル転送、HTTP応答、停止後のポート解放を確認した。 資格情報、VPSの接続先、非公開リポジトリのアドレス、個人PCのパスは掲載していない。

開発日誌 2026-08-05 — 調査記事を52社版へ深掘り

·34 文字·1 分
8月5日は、シリコンバレーへ進出する日系企業の調査を、候補集めから検証可能な記事へ仕上げた。 今日やったこと # 調査範囲をサンフランシスコまで拡大 # 実施内容: サンノゼからペニンシュラ、サンフランシスコまで再調査した。 結果: 一覧を25社から52社へ拡張し、一意な情報源は83件になった。 検証方法: 施設ロゴや地域マップは候補抽出に使い、現行拠点は企業発表、自治体・地域団体、業界団体、報道などで個別確認した。 掲載基準: 物理的な拠点利用とオンライン会員を分け、同じ「掲載企業」を一律に現地進出と扱わないようにした。 調査メモを記事の本筋から分離 # 問題: 初期版では、調査中に見つけた情報を後半へ並べすぎていた。 修正: 企業一覧と掲載基準を中心に据え、地域別の集積、進出の定義、掲載・除外基準だけを残した。 結果: 調査過程の脱線を削り、記事の問いを追いやすくした。 判断と学び # 最初に見つけた情報源を記事全体の軸にしない。 候補抽出用の情報源と、掲載を確定する検証用の情報源を分ける。 物理拠点、共同研究、投資拠点、オンライン会員を同じ意味で数えない。 AIが集めた情報は、列挙する前に記事の問いへ戻して削る。 検証 # 52社版の表示を確認した。 83件の情報源を確認した。 Hugoビルドと16件のテストを通した。 公開ページの応答を確認した。 資格情報、非公開リポジトリのアドレス、個人PCのパスは掲載していない。

開発日誌 2026-08-04 — 開発記録なし

·12 文字·1 分
今日やったこと # 記録確認 # 確認内容: この日のCodex履歴と非公開LLM Wikiを確認した。 結果: 公開できる開発作業の記録は見つからなかった。 扱い: daily-signalの自動記事は開発作業と分け、根拠のある記録が後から見つかった場合に追記する。 資格情報、非公開リポジトリのアドレス、個人PCのパスは掲載していない。

開発日誌 2026-08-03 — 開発記録なし

·12 文字·1 分
今日やったこと # 記録確認 # 確認内容: この日のCodex履歴と非公開LLM Wikiを確認した。 結果: 公開できる開発作業の記録は見つからなかった。 扱い: daily-signalの自動記事は開発作業と分け、根拠のある記録が後から見つかった場合に追記する。 資格情報、非公開リポジトリのアドレス、個人PCのパスは掲載していない。