はてなブックマーク

はじめに Rust Learning Labは、手元のRustコードを題材に、構文や型、所有権を説明してもらうためのCodex・Claude Code向けプラグインです。「この記号は何か」「なぜここで借用するのか」「この変更で何が変わるのか」といった疑問を、具体的なコードに沿って確かめられます。 github.com Rustを書き始めた人にも、コードは読めるけれど型や所有権を選んだ理由までは説明しきれない人にも使ってもらいたいと思っています。私が考えているのは、AIに何を任せ、何を自分で確かめるか、その判断を育てる機会を仕事の中にどう残すかということです。Rust Learning Labは、手元のコードを読み、小さく試し、判断の理由を整理するために作りました。 業務でコードを書くことが、一番の学習機会だった 以前は、私にとって業務が一番の学習機会でした。実装するには知らないことを調べる

はじめに Codex CLIには、会話を要約する /recap、出力をコピーする /copy、会話全体を書き出す /export があります。いずれも会話に蓄積された情報を扱う機能ですが、対象と用途が異なります。 この記事では、3つのコマンドの役割と、関連する /compact・/status・/diff との違いを整理します。要約、コピー、保存で何が得られるのか。現在のコードや検証結果は、どこで確かめるのか。この区別を押さえると、作業の再開やPRの説明に必要な情報を選びやすくなります。 会話の要約、出力のコピー、会話全体の保存 3つのコマンドは、扱う情報の範囲で分けられます。 コマンド 扱う情報 主な用途 /recap 会話の要約 作業の状況を把握する /copy 完了した返答や、選択した出力 説明文やコードを別の場所へ貼り付ける /export 会話全体のMarkdown記録 調査や判

はじめに 『Building Evolutionary Architectures, 2nd Edition』を読みました。要件や技術が変わり続ける中で、システムの設計をどう変えていくかを扱った本です。部品をどう分け、どうつなぎ、どこへデータを置くか。ここでいうアーキテクチャは、そうした全体の構造を指します。1か所を直すだけで済むか、ほかの部品や担当チームまで巻き込むかにも関わります。 中心となるのは、守りたい性質を確かめる「フィットネス関数」です。新しい機能が動くだけでなく、応答が遅くなっていないか、必要なセキュリティを保てているかも、日々の変更の中で確かめる。本書は、その検査の仕組み、変更しやすい構造、組織や継続的な改善を扱う3部で構成されています。コードを直したあとにどう公開するか、保守する時間を誰が用意するかまで議論が続きます。設計は、決めたあとが長い。 その長い時間に付き合う方法

はじめに Codexが修正している途中で、「なぜ、その判定を変えるのか」と聞きたくなることがあります。理由を知りたいだけなのか、その変更を止めてほしいのか。途中で送る一文にも、別の目的があります。 長い仕事を続ける /goal、途中の質問を分ける /side、実行中の指示変更と予約送信。それぞれ、作業を続ける条件、質問する会話、指示を送るタイミングを指定する操作です。9月のCLI更新では、下書きを残したままCodexからの質問へ答える機能も加わりました。 認証処理を直す仕事で考えてみます。修正は続けてほしい。でも、期限の判定については説明を聞きたい。必要なら仕様を決め直し、Codexへ変更を指示したい。説明を聞く会話と、実装を依頼する会話を分けて進められます。 learn.chatgpt.com この記事では、まず実行中の追加指示と次のターンへの予約を分けます。次に、説明を聞くサイドチャッ

はじめに Codexへ同じ種類の依頼を繰り返していると、会話を開いて文章を貼り付ける操作を省きたくなります。変更概要を作る、ログを整理する、確認すべき点を一覧にする。入力と出力が見えている仕事なら、codex execで既存のCLIの流れへ組み込めます。 JSONの形が正しくても、調査が成功したとは限りません。対象を読めなかった結果が「問題なし」の空配列になれば、後の処理は失敗に気づけません。この記事では、実行中のイベント、最後の回答、実行そのものの失敗を分けて受け取ります。 learn.chatgpt.com まず単発の仕事を渡し、次にJSONLのイベントと最終JSONを分けます。その後、保存先、失敗時の扱い、CIの設定、会話を続ける方法まで順に確認します。 構造化出力は、結果を次の処理へ運ぶための形式です。対象を読んだ範囲、使った入力、失敗した操作まで記録しなければ、整ったJSONが誤

はじめに 毎朝、前日に変わったコードを確認したい。レビュー待ちのPRも見に行きたい。繰り返す仕事には、手順が分かっていても、始めるのを忘れる問題があります。Codexの定期タスクを使うと、予定した時刻にその仕事を始められます。 毎朝同じ文章を送っても、前回の会話や対象ファイルがなければ、同じ仕事にはなりません。予定どおり始まっても、必要な情報を読めずに終わることがあります。実行する時刻と一緒に、何を渡して始めるかを決めます。 ここでは、ローカルプロジェクトの変更を朝に確認するタスクを作ります。ChatGPTデスクトップアプリ内のCodexから利用し、管理画面の Scheduled で予定と実行結果を確認します。 learn.chatgpt.com この記事では、まず実行場所を決め、毎回新しく始めるか会話を続けるかを選びます。その後、対象、権限、停止条件を固定し、最後に実行結果を読むところま

はじめに 会話を分岐しただけでは、ファイルは分かれません。修正案を2通り試していても、同じディレクトリを書き換えているなら、片方の変更はもう片方からも見えます。会話の中では別案でも、ディスク上では同じ実装を直している状態です。 Codexでは、会話の分岐にWorktreeを組み合わせ、作業場所も分けられます。共通の調査から別案を試し、それぞれの差分を比較できます。取り込む変更が決まったら、不要になった作業場所も片付けます。 Claude CodeのAgent viewの記事では、並行する仕事の編集場所をWorktreeで分け、最後に変更を統合する話を書きました。今回の主題は、Codexから会話と作業場所を分ける方法です。 syu-m-5151.hatenablog.com この記事では、まず会話とファイルの分離を確認し、次にCLIとデスクトップでWorktreeを作る流れを見ます。その後、

はじめに 同じ仕事を頼むたびに、前の会話からうまくいった指示をコピーすることがあります。その手順を残す場所として、Claude Codeの記事ではAgent Skillsを紹介しました。続くPluginsの記事では、社内で共有するSkillをプラグインにまとめる方法を書きました。配布した後も更新が届くところまで管理します。今回はCodexで同じことをするために、Skillを作る基準と、Codex固有の配置・呼び出し方を考えます。 syu-m-5151.hatenablog.com syu-m-5151.hatenablog.com PR説明を頼んだときは使ってほしいけれど、変更方針を相談しているだけなら、まだ報告書は作ってほしくありません。Skillには、正しい手順だけでなく、その手順を使う場面の見極めも必要です。別の環境へ渡すなら、同じ資料やツールを使えることも条件になります。 Skil

はじめに これまで、settings.json、CLAUDE.md、Commands、Hooks、Subagents、Skillsについて書いてきました。それぞれ設定すると、毎回説明することを減らせます。その次に困るのが、直した設定を、使っている環境へ届け続けることです。個人的にPluginsで嬉しいのは、自分のSkillをパッケージとして管理できることです。Skillを配布しても、その後の更新を忘れてしまうので。 たとえば、変更の概要を書くSkillを3つのリポジトリへコピーしたとします。1つで説明を改善したら、残り2つも更新する。Hooksも一緒に渡したいなら、設定ファイルへ追記する場所を説明する。コピーで配った手順は、直すたびに配り直す仕事が残ります。 社内で共有するSkillは、プラグインにまとめて配布することを勧めます。Skillの手順に加えて、インストール方法や更新方法を共通に

はじめに AIを使って仕事が楽になった、という人は定期的に現れます。どこかの偉そうな人から、エージェントに任せれば人は楽になる、と言われる。けれど、複数のエージェントを起動すると、減っているのは考える時間です。 セッションごとの入力待ちに答え、別worktreeの差分を読み、終わった変更を同じ状態で動かす。仕事の量が消えたわけではなく、労働密度が上がっていました。1つのターミナルを見続ける辛さとは、別の辛さがあります。 Agent viewは、この辛さを消す機能ではありません。複数セッションの状態を一覧し、入力を求めている仕事へ移るための機能です。セッション間通信は、決まったことを別のセッションへ送る機能です。この記事では、仕事を分ける条件、返事を送るタイミング、統合した変更を確認する手順を整理します。 2025年のCLAUDE.mdの記事では、Git Worktreeを作り、それぞれでC

はじめに Codexにテストを実行してほしいのに、依存パッケージの取得や書き込みで止まることがあります。そこで権限を広げると、今度はどこまで実行できるのかを説明しにくくなります。確認画面の多さだけを見て設定すると、必要な権限も分かりにくいままです。 権限プロファイルでは、ローカルのコマンドが触れるファイルや通信先をまとめます。Rulesでは、コマンドの引数列から許可・確認・禁止の判断を決めます。Claude Codeの権限設定と比べると、「どの操作を許すか」と「どの範囲なら任せるか」を分けて考える意味が見えてきます。この記事では、その設計の違いを押さえてから、テストが止まった場所と直す設定を順に確認します。 権限プロファイルはBeta、Rulesはexperimentalとして提供されています。組織の管理設定がある環境では、その制限も適用されます。 learn.chatgpt.com この

はじめに Codexで設定を残す場所は、主に2つあります。config.tomlは実行環境を、AGENTS.mdは仕事の進め方を決めます。 learn.chatgpt.com config.tomlにはモデルや推論の強さなど、実行時の条件を書きます。AGENTS.mdには検証方法や作業上の制約を書きます。役割は分かれていますが、ファイルを置いただけで意図どおりに効くわけではありません。 設定の優先順位、起動場所、読み込まれる指示を確認して初めて、同じ条件でCodexを使えます。この記事では、まず2つの役割を分け、次に設定の読み込み順とAGENTS.mdの探索範囲を確認します。 このシリーズでは、Claude Codeのsettings.jsonとCLAUDE.mdを分けて設定する方法を紹介してきました。Codexにも似た役割のファイルがありますが、読み込まれ方まで同じとは限りません。 sy

はじめに 「今週は検証環境が使えない」と伝えた文が、来月の会話にも残っている。期限のある事情を覚えているだけなのに、いつの間にか恒久的な手順になる。そうなっていたら困ります。覚えてくれることと、今も正しいことは別です。 以前のモデルが何度も間違えたために足した指示も、モデルを替えた後まで同じ書き方で必要とは限りません。消してよいのか、残すべきなのか。その判断をしないまま、設定だけが増えていきます。 昨日の記事では、/skill-doctor でSkillsの使われ方を調べ、モデル更新時に指示を見直す話を書きました。今回は、その続きを .claude/rules/ とAuto memoryで考えます。自分で書いたルールも、Claudeが会話から残したメモも、その後の仕事に合わせて手入れしていきたいです。 syu-m-5151.hatenablog.com Rulesは、対象に応じて指示を読み

はじめに 2025年12月に「Claude Codeの Agent Skills は設定したほうがいい」という記事を書きました。必要な手順を必要なときに読み込ませる仕組みとして、Skillsを紹介した記事です。ただ、後半では設定が増えるほど管理が難しくなる話もしました。どれが使われているのか。似た説明のSkillが、互いの出番を奪っていないか。 syu-m-5151.hatenablog.com 今回は、その続きです。Skillsをいくつも設定した人には、まず /skill-doctor を紹介したいです。設定を増やす前に、今ある設定の使われ方を見られます。 /skill-doctor はv2.1.252以降の機能で、8月31日〜9月4日の公式更新で紹介されました。 code.claude.com このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉し

syu-m-5151.hatenablog.com はじめに 一年で、こんなに価値観が変わるとは思っていませんでした。 私は「技術力に優劣はある」という記事で、技術との向き合い方を「道具として使う」「理解する」「創る」に分け、それぞれの中にも上手下手があると書きました。市場はその差を評価する。学びを続けた人ほど選択肢が広がる。コミュニケーションが得意でも、技術を学ばなくてよい理由にはならない。この主張は今も間違っているとは思いません。 エンジニアのキャリア地図 「技術」と「やりたいこと」から見つける最適解 作者:サカモトソシムAmazon その記事を書いた時にも、AIコーディングエージェントはありました。けれど、私はまだ、個人が使いこなす道具として見ていました。いまは、エージェントがリポジトリを読み、実装と検査を進めます。別のエージェントへ作業を渡し、人間が見ていない時間にも進みます。この

はじめに 私たちは、明確なゴールを決めずにコードを書き始めていた。 書いて、動かして、また直した。 AIエージェントを使う今、それは過去の話ではない。 コードから考え始めることには、もっともな理由があります。動くものがあれば話は具体的になり、間違いにも早く気づけます。AIエージェントは、このやり方をさらにやりやすくしました。曖昧な依頼からでも、画面、API、テストまで一息に作れます。 ただし、速くなったのはコードだけではありません。検討中の案、採用した要求、実装条件を区別しないまま、誰かの要望が動くソフトウェアへ変わる速度も上がりました。完成したコードから、「なぜ作るのか」「誰が何を達成するのか」「どの損失を避けるのか」「誰が判断したのか」を復元する仕事は残ります。 要求工学は、曖昧な言葉を長い文書へ膨らませる技術ではありません。要望の背後にある目的を確かめ、利用者の仕事へつなぎ、観測でき

はじめに Suikoは、日本語文書の自然さと読みやすさを、再現可能なルールで診断するRust製のCLIです。禁止語や翻訳調に加え、均一な文のリズム、段落構造、用語の初出、読解負荷まで確認できます。ただし、文章がAIによって書かれたかは判定しません。怪しい箇所を同じ条件で指し示し、直すか残すかの判断を人間やエージェントへ返します。 github.com Suikoの出発点は、cojiさんのNatural Japaneseです。このAgent Skillは、文章を書く前の設計、書くときの制約、書いた後の検査を一体として扱います。定型句を置換するだけで終わらず、機械が疑いを検出し、文脈を読める人間やAIへ判断を返すところまで設計されています。文章を道具で直しすぎないための責任分担が明快で、私はこの考え方に強く納得しました。 私が触れてきた自然言語処理の道具も、Pythonを前提とするものが多くあ

はじめに Topcoatは、HTMLをサーバーで生成しながら、ブラウザ上の状態更新やサーバー処理もRustで記述するフルスタックフレームワークです。フロントエンド用のディレクトリやnpmを用意せず、1つのRustファイルから動きます。2026年7月に発表された0.5.0を検証しました。 サーバーサイドレンダリング、部分的な反応、セッションの転送層までは任せられます。認証、マイグレーション、運用はアプリケーション側に残ります。この記事は、その境界を1つずつ確認した記録です。 github.com tokio.rs SSRとルーティングは1ファイルで済む Rust 1.95以上を用意し、Topcoat 0.5.0とTokioを追加します（検証は1.97.1）。 cargo add topcoat@0.5.0 cargo add tokio@1 --features rt-multi-threa

はじめに CodexやClaude Codeに作業を任せ、その間にNeovimで別のコードを編集します。これは便利です。しかし、エージェントの状態を確かめるたびに端末を順に開き、止まっていればそこで返事をします。これを繰り返すうちに、Neovimよりターミナルを見ている時間が長くなります。 正直に言えば、効率だけの問題ではありません。私は、自分の手に馴染む開発環境を自分で育てることを、PDE（Personal Development Environment）として続けてきました。エージェントが増えても、コードを読み書きする場所をNeovimから端末へ移す理由はありません。作業を任せたエージェントにターミナルまで占領されるのは、さすがに生意気です。まだ、許しません。 syu-m-5151.hatenablog.com ただし、エージェントそのものをNeovimで動かすわけではありません。端末

はじめに 最初から完璧な成果物は存在しない。 ただ出して、直して、また出した人がいるだけだ。私の場合、それが29本の「おい、」だった。 「おい、」シリーズは、形にならなかった本の原稿から始まりました。本を出せなかったときは、やはり少し絶望しました。それでも、書きかけの原稿まで消えたわけではありません。1冊へまとめず、原稿を1本ずつブログとして終わらせました。 最初から上手に書けるわけではありません。書き始めた頃の文章は、普通に不格好です。不格好なものを外へ出せば、ある程度はバカにもされます。ここは、たぶん避けられません。 ところが、1年も続けていると、だいたいの人は飽きます。批判が減る。ありがたい。しかし、注目も一緒に減ります。批判だけが消えて、関心だけが都合よく残るわけではありません。 最初の数本は、「おい、」と自分へ命令する形式そのものに驚きがありました。29本目ともなれば、タネはもう

はじめに 生成されたコードを、十分に読まずにマージした。 障害は起きなかった。原因を半日追うような挙動も、出なかった。 払っていることに気づいたのは、ずっとあとだった。 壊れてくれるなら、まだ分かりやすかったのだと思う。実際に起きたのは、どの変更も動いていて、どの変更も少しだけ説明できない、という状態がゆっくり広がることだった。一つずつなら思い出せる。並べると、なぜこの形なのかを言える範囲だけが減っていく。ある日リポジトリを開いて、自分が説明できない側のほうが多いことに気づく。コードベースは、いつのまにか広大になっている。 要約は読んでいた。「入力を検証し、データを保存し、結果を返す」。その説明は正しかったのだと思う。ただ、途中で失敗したときに何が残るか、同じ要求が届いたときに何が重なるかは、そこに書かれていなかった。変更が何を前提にしていたかを回収する費用は、障害という一括の請求では返っ

はじめに 個々の関数は読める。使われている概念も知っている。 それなのに、値の変化と呼び出し順と失敗時の戻り方を一緒に動かそうとすると、前に見た関係が抜け落ちていく。 足りないのは、たぶん理解力ではない。 同じ関数をもう一度開く。さっき確かめたはずの分岐を、もう一度目で追う。追っているあいだに、その前に確かめた状態のほうが消える。長いコードを前にして私が感じるのは難しさというより、この往復である。 この状態で説明を増やしても、必ずしも楽にはならない。情報が足りないのではなく、考えるために一時的に保持できる量を超えているからだ。 生成AIは私より長いコードを一度に受け取り、関係を要約できる。扱えるコンテキストが広がるほど、複雑さもまとめて外へ任せられるように見える。けれど、その要約を読み、どの関係が正しいかを確かめ、変更の影響を引き受ける私の注意まで同じ割合で広がるわけではない。 生成AI時

はじめに 生成させたRustのコードはコンパイルを通り、小さな入力を使うテストも通った。 use std::io::{self, Read}; fn read_stream(mut input: impl Read) -> io::Result<Vec<u8>> { let mut bytes = Vec::new(); input.read_to_end(&mut bytes)?; Ok(bytes) } unsafe はない。借用規則にも違反していない。それでも、この関数には入力の上限がない。read_to_end はEOFまで読み込んだ内容をVecへ追加する。入力が大きければメモリを使い続け、入力元が閉じなければ読み込みも終わらない。型安全であることと、運用時の資源に上限があることは別だった。 この六行が、既知の事故で使われたコードというわけではない。それでも、問題の型は仮想ではない

はじめに 知らない名前があれば止まり、呼び出し先を開く。そこにもまた、知らない名前がある。 かつての私は、そうやって定義から定義へ移っていた。 たどり着いたころには、最初に何を知りたかったのかを忘れている。 戻る道は残っていた。開いたタブは全部そこにある。それでも、なぜ最初のファイルを開いたのかだけが出てこない。仕方がないので、また先頭から読み始める。 あのころ読むのが遅かったのは、目の動きが遅いからではない。すべてを同じ重要度で読み、一度に扱える量が限られた注意へ、目的、現在地、通過した経路、細部を同時に載せていたからだ。最初に載せた目的が、いちばん先に落ちる。 いまはAIにコードを調べさせ、実装も任せれば、入口、主要な処理、依存の候補だけでなく、動く初稿まで早く得られる。私の作業でも、以前より多くの案を少ない人数で試せるようになった。それでも、どこを一つのまとまりとして見て、どの目印を

はじめに 私はFable 5の性能を語りたい。そして、その前に自分のSkillを疑いたい。 以前のモデル向けに書いた指示は、新しいモデルでも動きます。 しかし、動くことは、能力を引き出すことを意味しません。 Prompting Claude Fable 5という題名から想像するのは、Fable 5に効く指示文の一覧です。ところが本文には、タイムアウト、ストリーミング、メモリ、サブエージェント、フォールバック、send_to_userまで並びます。プロンプトの話を読みに来たはずが、途中からクライアント、実行基盤、UI、権限管理の話を読んでいる。題名はプロンプトですが、読み終わるころには実装チケットが増えています。少し話が違う。そこが本題です。 platform.claude.com この文書は、うまい言い回しによってモデルの能力を引き出すためのプロンプト集ではありません。長時間動き、ツールを

はじめに 前の記事に、「何が分からないか分からないとき、どう乗り越えているのか」というコメントをもらいました。 syu-m-5151.hatenablog.com 同じ問いは、学生からも、SNSでも、以前から聞かれていました。 その場では断片的に答えてきましたが、1つの形にしたことはありませんでした。 ただ、この問いに1つの記事で答えようとすると、手が止まりました。私も、新しい領域では何が分からないのか分かりません。用語を調べると、その説明に知らない用語が出てきます。公式ドキュメントを開いても、どのページから読めばよいのか判断できません。AIに聞けば整った説明は返ってきますが、どこを信じ、何を確かめればよいのかが分かりません。 正直に言えば、私はこの状態を一度には乗り越えていません。そもそも、乗り越えるという捉え方が少し違います。そのことに自覚的になったのは、ソフトウェア開発の仕事で、それ

はじめに 学生は、私より先にAIへ質問していました。 AIはすでに答えていました。 それでも、問いを持ち帰ったのは私でした。 コンテナやKubernetesの基礎を扱う学生向けのワークショップで、学生たちはAIエージェントに実行を任せていました。分からないことがあれば、まずAIに聞きます。その回答を読んでから私に質問し、私は答えます。ときどき、「どこまで確かめたのか」と問いを返しました。 これは、学生やジュニアエンジニアのAI利用を評価する話ではありません。私も日々AIエージェントを使っています。ただ、その往復が滑らかに進むほど、「できた」という言葉の輪郭がぼやけていきました。 速く実行できることと、上達していることは同じなのでしょうか。同じ問いは、コードレビューを受けながら既存の設計や変更の影響を学ぶジュニアエンジニアにも残ります。 私はソフトウェアエンジニアなので、この問いをソフトウェ