AI開発ツールの供給と制約が同じ日に動き、日本語圏では運用の詰め方が上位を占めた

Apple純正のフレームワークを使う点が特徴で、従来はCorelliumのような商用サービスが担っていた領域にあたる。

コメントでは、テストやリバースエンジニアリングの選択肢が広がるという期待が並ぶ一方、SIPの無効化が必要で他の機能を壊しうるという懸念が出ている。Corelliumが研究用途限定になり、アプリのプロファイリング手段を失ったという報告も。

READMEにある「iOSの初期設定で地域に日本やEUを選ばないこと（VMが満たせない規制チェックが増える）」という注意書きについて、具体的に何を指すのか問う声が出ている。

EVE Onlineは長くStackless Python 2の上で動いてきた。記事は移行の開始を告げるもの。

コメントでは日付を確認したという反応が並ぶ一方、Goldman SachsやJP Morganも数年前までPython 2.7を基幹言語として維持していたという指摘が出ている。

Stacklessのtaskletと継続はエージェント時代の長時間実行タスクに向いていたはずで、asyncioとは別の可能性があったという見方も。240万行への解決策が「性能を理由にさらにPython」であることへの皮肉も出ている。

バージョン番号の飛びについて、htmx 3.0を出さないという過去のエッセイでの宣言を守った結果だと説明されている。

コメントの中心は、長期開発でターゲットのIDがずれていく「ドリフト」をどう防ぐかという質問。htmxはコンパイルされないので自動検査はなく、テストで大部分は補えるが完全には防げないという回答が出ている。

利用者からは、大規模で複雑な対話型アプリには使わない、複数箇所を同時に差し替えるとき以外はIDを使わない、といった運用が挙がった。サーバ往復が中心でクライアント側の状態が肥大しないなら複雑なアプリでも十分機能する、という反論も出ている。

一見不可能に見える再現条件から原因を特定していく、デバッグ事例の古典として扱われている。

コメントでは、同じ系統の話として「500マイルより遠くにメールが送れない」（2002）が挙げられ、どちらもThe Cursed Computer Icebergに収録されているという情報が出ている。

IEFBR14という1命令のプログラムにバグがあった話、jargon fileの「more magic」、Excelが原因で遺伝子名が改名された件など、関連する逸話が続けて紹介されている。

LLMの冗長な出力に名前を与える記事。カジュアルな雑談や情報の垂れ流しを指す既存の語を転用している。

コメントでは、「vibe」を既にLLM文脈に取られた後でさらに良い語を明け渡したくないという意見、半年後には「気に入らないもの」全般を指す誤用が広まるだろうという予測が出ている。筆者本人もそれはありうると認めている。

対策として、AGENTS.mdでSTE100（Simplified Technical English）での記述を義務づけているという報告があった。セッション中に指示を忘れるモデルには再指示が要るが、冗長さはかなり減るとのこと。

ノートPCのスピーカー品質をソフトウェア側で補正する用途を扱っている。

コメントでは、AutoEqのプロファイルを読み込ませたカスタムイコライザとしても有用でヘッドホン利用者にも勧められる、Linux Studio Pluginsを扱うGUIとしても機能する、といった補足が出ている。

一方で、単純なEQプロファイルの適用ならGTKのGUIを通さずPipeWireへの一度きりの読み込みで済ませたい、という意見が出た。8.0からQt/Kirigamiに移行しているため、EQ適用のためにQtとKDEフレームワーク一式を持ち込むことになるという指摘も。

gtk4-layer-shellに依存する構成で、Guileで拡張できる点が特徴として挙げられている。

コメントでは、Guileのfibersや、SpritelyのGoblinsと組み合わせる案が出ている。

GNOMEがlayer-shellを実装していない点については、wlrootsから来たプロトコル拡張であり、GNOMEは歴史的に自前以外のプロトコル拡張に消極的だった、という説明が付いた。

プロファイリング結果をもとに改善点を絞り込む過程が中心の記事。

コメントではフレームグラフの取得方法が質問され、`-Z self-profile` でデータを集め、measuremeのcroxでChromeトレース形式に変換し、Perfettoで可視化する手順ではないか、という推測が返っている。

Rustの安定版リリース前にCraterでエコシステム全体をテストする仕組みにも反応が集まった。crates.ioとGitHub上のRustリポジトリをすべてビルドするもので、PRの実験にも使われるが、並列実行のリソース制約から偽の失敗が出ることもあるという補足が出ている。

エージェントやモデルの学習パイプラインが技術文書をどう読むかについては、テクニカルライターの間でもまだ議論が続いているという前置きで共有された。GEOはGenerative Engine Optimisationの略。

コメントでは、そもそもllms.txtはSEO目的で作られたものではなく、エージェントがサイトを使うための情報提供が本来の趣旨だという指摘が出ている。

記事の「HTMLは人間向けにナビゲーションや広告で情報を包んでおり、テキストへの復元が難しい」という主張に対し、階層的なナビゲーションや全画面リロードのない操作は人間にとって歓迎されるものだ、という反論も並んだ。

Cursor、Claude Code、Codex CLI、OpenCode向けのレンダリング・検証システム。エージェントは図そのものではなく型付きJSONのIRを生成し、Archifyがそれを決定論的にHTML/SVGへ変換する構成をとる。

図は5種類、プリセットが4つ、ダーク/ライトテーマと有限のモーションを備える。2つの検証済みスナップショットをBefore / Delta / Afterで比較し、追加・削除・変更・移動・経路変更を列挙する機能があり、マージ前のアーキテクチャ差分レビューを想定している。

出力は単一ファイルで完結し、HTMLに加えてPNG、SVG、WebM、1200×630のシェアカードを生成する。ノード検索、リビジョン検証済みのソース参照、上流・下流の到達経路の追跡が、トポロジを捏造しない範囲で行えるとしている。MITライセンス。

YouTubeで累計500万回以上再生された「God's Eye View」シリーズ（旧WorldView）から生まれたプロジェクトのオープンソース化。3D地球儀に、航空機・船舶・衛星・地震・交通・公開カメラのライブデータを重ねる。

ライブ映像が得られない箇所は、モデル化された表示であることを明示する設計になっている。リアルタイムAIエージェントによる音声操作にも対応する。

READMEにはAPIキーの取得と、実際にかかる費用の項目が独立して用意されている。データ源はすべて公開情報であり、そこが企画の主眼だと説明されている。

任意のAIエージェントを研究用途に向けるためのスキルライブラリ。バージョン2.65.0時点で163のスキルと100以上の科学データベースを収録する。

Agent SkillsとAgent Pluginsの両標準に対応し、Cursor、Claude Code、Codex、Googleの各環境で動作するとしている。リポジトリにはセキュリティスキャンとスキルテストのGitHub Actionsワークフローが用意されている。

ライセンスはMIT。生物学をはじめとする分野を対象に、データベース接続を含めた形でスキルが整理されている。

AIコーディングアシスタントを動画制作の作業環境として使うためのシステム。12の制作パイプラインと100以上のツール、700以上のエージェントスキルおよび制作知識ファイルで構成される。

READMEには動画を貼り付けて始める導線、試すためのプロンプト例、パイプライン一覧、レビューガイド、エージェント向けガイドが並ぶ。複数のAIエージェントを1つの会話で協調させるサービスと、動画・画像生成とLLMを単一APIで扱う推論基盤が、スポンサーとして前面に置かれている。

Tailscaleのオープンソース部品を組み替え、magicsockによる2台間のWireGuard暗号化トンネルだけを取り出したもの。NAT越えの側路と、最終手段のリレーとしてDERPを使う。

Tailscaleのコントロールプレーンは使わず、接続に必要なメタデータはすべて帯域外でやり取りする。片側がサーバ（リスナー）として起動すると短い接続トークンが返り、もう片側がそれを渡して接続する。

CLI (`cmd/tailcat`) はGoライブラリ `github.com/tailscale/tailcat` の上に構築されており、ライブラリとしても利用できる。両者間の通信はすべてWireGuardでエンドツーエンドに暗号化される。

スクリーンショット、モックアップ、Figmaデザイン、画面録画をコードに変換する。出力先はHTML+Tailwind、HTML+CSS、React+Tailwind、Vue+Tailwind、Bootstrap、Ionic+Tailwindから選ぶ。

既定のモデルとしてGemini 3 Flash PreviewとGemini 3.1 Pro Previewを最良と位置づけ、GPT-5.5 / GPT-5.4 Mini、Claude Opus 4.6 / 4.8を併記している。画像生成にはReplicate経由のz-image-turboを使う。

ローカル実行とホスティング版（screenshottocode.com）の2つの導線が用意されている。動作中のサイトを録画したものから、機能するプロトタイプを起こす使い方にも対応する。

`/plugins` にAnthropicのメンバーが開発する内部プラグイン、`/external_plugins` に第三者のプラグインを置く構成。`/plugin install {plugin-name}@claude-plugins-official` で導入するか、`/plugin > Discover` から探す。

READMEの冒頭には、インストール・更新・利用の前にプラグインを信頼できるか確認するよう警告が置かれている。プラグインに含まれるMCPサーバやファイルはAnthropicの管理下になく、意図通り動くことも内容が変わらないことも保証しない、と明記されている。

外部プラグインは品質とセキュリティの基準を満たすことが提出の条件とされている。内部プラグインの参照実装として `/plugins/example-plugin` が用意されている。

if-elseの代わりに `max(a, b)`、手書きのループの代わりに `slices.Contains`、nilチェックの連鎖の代わりに `cmp.Or(a, b, c)` を使わせる、といった置き換えを扱う。Go 1.26で入った `new(42)` や `errors.AsType[T](err)` も対象に含む。

対象範囲はGo 1.0から1.27までで、`modernize` アナライザが扱う内容をすべて含む。完全な一覧と説明はFEATURES.mdにある。

エージェントはgo.modからプロジェクトのGoバージョンを検出し、そのバージョンまでに利用可能な言語機能と標準ライブラリの追加を使う。動機として、コーディングエージェントが古いGoを生成しがちである点が挙げられている。

ワールドモデルのスケーリングでは、クロールした動画と計算資源を増やすだけでは非効率で、根拠のある報酬信号を出す再帰的なデータエンジンが要る、というのが出発点。コードエージェントの成功は、コードが実行可能でコンパイラやランタイムが高品質な報酬を返せることに支えられている、と対比する。

空間生成は今もCLIPスコアのような曖昧な代理指標に依存しており、信号が曖昧かつ偏るためRL事後学習を支えにくい。これに対しゲーム開発は、報酬環境として欠けていたものを供給するとする。

ゲームエンジンで符号化されたシーンは実行可能な世界仕様であり、衝突、物理、移動可能性、遊べる範囲を効率的に検査できる。全体としての検証信号は、そのシーンを受け入れるかどうかを判断する開発者が与える。ゲーム開発はRL事後学習向けの長期軌跡データも供給する。

多くの物理過程は複数の妥当な展開を持つため、ワールドモデルは妥当な1本の軌跡だけでなく、同じ初期観測と行動のもとで起こりうる挙動の分布も再現すべきである、という要求を「確率的整合（probabilistic alignment）」として定式化する。

既存の評価は動画1本ごとの妥当性を測るもので、生成を繰り返したときに正しい分布が復元されるかは検証していない。そこでPAWBenchを導入し、動画生成器を世界ダイナミクスの確率的サンプラーとして評価する。

併せてPAWEvalという結果レベルのプロトコルを導入し、反復したロールアウトを起こりうる物理挙動上の経験分布に変換する。50シナリオ・現行11システムでの評価では、参照分布に一貫して一致するモデルはなかった。

MLLMはストリートビューを解釈できるが、都市での行為能力は、その局所的な証拠がエージェントが動き出した後も有用であり続けるかにかかっている、という問題設定。

UrbanGroundは、香港の全域3D地理空間データから構築した物理的制約のある複製上で、この問いを検証可能にする最初のサンドボックス。一人称視点での閉ループ操作と、航法用の対話的な地図を備える。

分析は3つの研究課題で進む。能動的に観察した後に空間的な質問に答えられる程度まで局所シーンを接地できるか、目的地が遠く曖昧になっても接地が航法を支えるか、経路の利用可能性や歩行者の変化に対して挙動が維持されるか。

RLやOn-Policy Self-Distillation (OPSD) は数学推論を大きく前進させたが、正解ラベルへの依存によりテスト時学習ができない。多数決の疑似ラベルで代替する方法は、投票が誤ると教師が壊れて全トークンを誤導するため脆い。

著者らは、この失敗が非対称であることを観察する。疑似ラベルと一致しないロールアウトは、投票自体の正誤にかかわらずたいてい誤っている。ここからTTPOを提案し、一致するロールアウトをOPSDで蒸留し、一致しないものをGrouped RLで罰する。

さらにトークンレベルの選択を加え、蒸留では既に収束した位置の重みを下げ、RLでは確信度の高い誤りだけを罰する。疑似ラベルの誤りが頻繁でも両方の更新が破綻せず、モデルが改善するにつれ多数決ルーティングがより厳しい自己教師を生む。

オンポリシー蒸留（OPD）は事前学習済みの専門教師モデルから密な教師信号を得る手法で、LLMで成果を上げ、近年フローマッチングモデルにも適用された。ただし目的ごとに専用の教師を学習するコストが高く、教師と生徒の分布のずれが生成軌跡上で誤差を累積させる、という2つの問題がある。

Self-OPDは、生徒自身の自己探索をステップごとの教師信号に変える、教師不要のOPDフレームワーク。各時刻で決定論的な次状態予測をK個の確率的SDE候補に分岐させ、ODEサンプラーで展開し、決定論的な自己参照ベースラインと報酬を比較して正規化アドバンテージを得る。

速度場は全分岐のpull-push目的で最適化され、アドバンテージの高い分岐が生徒を引き寄せ、低い分岐が押し返す形になる。

LLMエージェントは外部環境との対話を学ぶために生成データへの依存を強めている。生成は環境・タスク・対話・成功信号の間で整合を保ちつつ、単に大量なだけでなく有用な経験を作る必要がある。既存研究はドメインごとに整理されがちで、生成機構の共通点が見えにくく、候補生成と検証・選択が混同されている。

本稿は2階層の枠組みを立てる。まずエージェント用データを (E, q, τ, v) — 環境仕様、タスク信号、対話の実現、任意の検証器 — という因子分解された共通オブジェクトとして表現し、生成パラダイムを主たるアンカーと依存構造で分類する。

次に生成を、Accuracy-Complexity-divErsity (ACE) のレンズによる制約付き分布設計として定式化する。Accuracyが接地され内部整合したデータの実行可能な台を定め、その中でComplexityが学習者に相対的な位置へ学習の質量を置く。

AIによるデジタルアバター配信者は、商品の質問への回答、視聴者との対話、マーケティング戦略の実行をリアルタイムに行う必要があり、低遅延、頻繁な戦略更新、正確かつ効果的な応答が求められる。

Skills、Hooks、プロンプト、ツールをモデル重みと独立に更新できるEvolvable Harnessは高速な反復を可能にするが、トレードオフを生む。大きなモデルはゼロショットで適応するが遅く、小型モデルは遅延要件を満たすが固定のハーネス構成に過適合する。

提案するHarness-Aware Training (HAT) は、変化するハーネスへ小型モデルを適応させる。中核のHarness-State Augmentation (HSA) は、Skillの識別子と内容、ツールスキーマ、プロンプト構造、Hook関数に対しタスクを保つ変換を適用する。学習はHSA-SFT、General On-Policy Distillation、HSA-RLの3段階で進む。

現代のビデオゲームは一人称視点の知覚、急激な視覚変化、持続する世界状態、多様なネイティブ操作を併せ持つ。既存のゲームエージェントは視覚とタスク文脈を直接行動へ写すが明示的な世界ダイナミクスを持たず、対話的なゲーム世界モデルは与えられた行動から視覚的未来を予測するがタスク方策にはならない。

World-Action Models (WAM) は両者を統合するが、ビデオゲームのダイナミクスと開放的な対話のもとではほとんど未探索だった。GameWAMは、著者らの知る限り、ネイティブな閉ループのゲームプレイとGUI制御に対する最初のWAMとされる。

並列の視覚生成過程と行動生成過程を、ブロック因果の条件付けとフローマッチングで結び、将来の観測とキーボード・マウス軌跡を同時に生成する。多様なネイティブ操作に対応するため、各行動ステップでgameplay/GUIのモードを予測し、モード別の予測分布と連続行動の正規化を用いる。

長期のエージェント実行が生む経験は、現在の実行と将来の作業の両方を改善しうる。しかし多くの自己改善手法は実行終了後にしか経験を処理せず、進行中の実行を修正することも、そこで得た教訓を即座に適用・検証することもできない。

著者らは自己改善はライブであるべきだと主張する。既存のアーキテクチャはこれを十分に支えない。単一エージェントの自己修正はタスク実行と軌跡評価を同一コンテキストに詰め込み、サブエージェント委譲は実行を分離するものの、動作中のサブエージェントを普通は誘導できない。

PILOTは2つの機構を組み合わせたsupervisor-workerハーネス。ライブ操舵は独立した監督役が実行中のワーカーを方向転換または中止させ、ライブ自己進化は実行中に露呈した手順と失敗モードを再利用可能なスキルと記憶へ蒸留する。凍結した2つのバックボーンと3つのベンチマークで、6構成中5構成で1位となった。

学習時に見たことのない操作タスクを実行するゼロショットのタスク間汎化は、ロボット学習の中心的課題として残っている。LLMでは新しいタスクを文脈で指定するだけでパラメータ更新なしに実行できる。この文脈内学習の枠組みをロボット操作に持ち込む。

著者らは、操作タスクの自然な指定方法は人間の動画だと主張する。言語と違い、意図したタスクの進行について豊かな視覚的手がかりを与えるためである。Zero-WAMは、文脈内の人間動画のガイドに従って未見のタスクを実行する因果的な動画・行動モデル。

タスクの多様性を持つ人間-ロボットの対応データが乏しい問題に対し、タスクをサンプリングしたロボット軌跡を意味的に対応する人間動画へ変換する自動パイプラインを提案し、8.6千タスクにわたる7.42万組のHumanGenを構築した。学習にはin-context future chunk prediction (IFP) の目的も導入する。

運用設計ラボによるssmonline #53の発表資料。手順書の設計思想と更新の運用を扱っている。

コメントでは、手順書は書いた時点が完成ではなく間違えられた箇所を足していくものであり、更新の担当と頻度まで決めないと読まれない一枚で終わる、という整理が支持を集めている。そもそも読まれない、という指摘も。

批判的な反応も多い。人的ミスは必ず起きるので最終的には指差確認とダブルチェックに落ち着く、実際に作ると机上の空論になる、という実務からの声、「運用手順書の設計思想」あたりから方向性が怪しくなり、結局「ミスを許さない手順書」は出てこなかった、という指摘が並ぶ。

Claude CodeやCodex CLIを使う開発者向けに、技術負債（品質と設計の犠牲）と理解負債（コードベースへの理解の遅れ）を分けて論じている。細かい実装は見なくてよくなっていくが、仕様を把握して自分の言葉で説明できることは必要であり続ける、というのが筆者の立場。

コメントは割れている。理解負債が溜まった状態はクソコードで技術的負債が溜まった状態よりましではないか、という見方、Claude Codeハッカソンの入賞者5名のうち4名が非エンジニアだったことを挙げてこの種の知識はもう価値がないという意見が出ている。

一方で、PRマージごとにルールを人間と検討しIssue/PRに議論の履歴が残っていれば不要だという運用報告、法務のようにコードと違って触法性が問題になる分野では理解を手放せないのではないか、という懸念も並んでいる。

AIに開発を丸投げすると、技術負債と理解負債の2つが溜まると整理する。技術負債は短期の速度を優先した結果の品質・設計の犠牲で、AIコーディングでは一度に生成される量が多いため蓄積が人間の開発時代より圧倒的に速い。既存の共通処理を使わずに同じ役割の関数を作る、既存コードとの統一感を無視する、といった例が挙がる。

理解負債は、自分が書いていないコードが増えることで「何をしているか」「なぜこの実装か」が分からなくなる現象。溜まると誰も仕様を把握しておらず、重要な改修が困難になるとしている。

筆者の立場は、コードの細かい部分は徐々に見なくてよくなるが、仕様を把握して自分の言葉で説明できることは必要であり続ける、というもの。前提としてClaude Code、Codex CLI、ghコマンドを使える状態にしておくことを必須に挙げている。

筆者の現在の運用は、退勤直前にタスクを投げてPCを閉じ、寝ている間にテストとAIによるレビュー修正まで回ってPRが上がってくる、というもの。手を動かすのは、止まったエージェントを起こすことと、承認が必要なものを確認・許可することの2つだけだとしている。

傍証として、Matt Pocockの「ローカルの開発環境から離れつつある」という投稿、SpaceXAIのLauren Tanの「worktreeは死んだ、クラウドエージェントが未来だ」という投稿を挙げる。Cursorではマージ済みPRのうちクラウドエージェント由来が、昨年12月の10%から2026年7月末に56%まで伸びたという数字も引いている。

記事は、クラウドエージェントの定義、どこまでクラウドに出せるか、何がローカルに残るか、という順で構成されている。筆者自身もローカル作業がゼロになったわけではないと断っている。

よく使う設定を盛り込んだテンプレートリポジトリ next-template の解説。名前に反してNext.js専用ではなく、React RouterやTanStack Routerでも使う。`.claude/skills/` に置いたカスタマイズ用テンプレートで、フレームワークやライブラリを差し替えたり落としたりできる。

最近の主な用途は、既存プロジェクトでAIエージェントに「このリポジトリのこの設定を取り入れて」と指示すること。良い構成はアプリの性質やチームによるため、全部を取り込むより部分的に参照させる使い方が多いとしている。

pnpmを選ぶ理由としてサプライチェーン攻撃対策が挙げられている。公開から指定した分数が経っていないバージョンを解決しない `minimumReleaseAge` などの設定を、テンプレート側で有効にしている。

ループエンジニアリングのコアモジュールとして挙げられる6要素（Automations / Worktrees / Skills / Connectors / Sub-agents / Memory）のうち、筆者はAutomationsのイメージが掴めていなかった。Claude Codeでauto acceptをonにすればそれで足りるのか、という程度の解釈だったという。

記事は、ループエンジニアリングを意識しない開発フローで簡単な開発を行い、その手法をループエンジニアリングと照らし合わせてフィードバックを取り、印象に残った4点から共通する2つの学びを引き出す、という構成をとる。

余談として、得られた学びをリポジトリごとに実装し直すのは大変なため、インストールするだけでループエンジニアリングを実践できる開発キットを作った経緯も併記されている。

SNSでよく見る「AIエージェントを24時間動かして開発を完全自動化した」「寝ている間もAIがコードを書いている」といった投稿への違和感から始まる。筆者は、そうした投稿が伸びやすく、注目がフォロワー増や有料noteの販売、PV収益に直結する構造を指摘する。成果が出ているかとは無関係に「凄そうに見せること」自体に経済的な誘因が働く、という整理。

コスト面では、LLMのAPIが従量課金である以上、高品質モデルの常時稼働はトークン消費が青天井になり、個人開発者の予算では現実的でないとする。安いモデルに落とせばよいという発想には、出力精度が下がるという罠があると続く。

記事は、常時稼働という発想がなぜ設計として破綻しているか、プロダクト開発の本当のボトルネックはどこかを整理する構成。発信者全員がそうだとは言わない、という留保も置かれている。

Agent IDEはAIを複数並行させる用途に向く代わり、個々のファイル編集や閲覧の機能は最低限になる。筆者は体感として、4以上のセッションを扱うならAgent IDEを勧めている。git worktreeの自動作成やタブでのセッション切り替えは既に一般的なので言及しない、という前置きも置かれている。

評価の中心は内蔵ブラウザ。並行開発で重要なのは脳のコンテキストをいかに速く切り替えるかで、開発ではAIとのチャットよりブラウザのほうが重いコンテキストになる（GitHubのPRタブ、動作確認用タブ、Google SheetsやSlack）。内蔵ブラウザならセッション切り替えでタブ群も一緒に切り替わる。

cmuxやSupersetでは、1セッション1タブで複数タブが使えない、パスキーが使えず各種ログインができない、といった制約があったと具体的に挙げている。

タスクを投げて別作業に移り、戻ったら権限確認ダイアログで15分止まっていた、という体験が出発点。ターミナルのベルもデスクトップ通知も定着しなかったため、通知ではなく「状態そのものを机の上に置く」方向に切り替えている。

構成は、約1,800円のM5Atom Liteを3Dプリントしたフィギュアに入れ、LEDの光をハート型の窓から透かせるもの。待機は青の常灯、作業中は白の呼吸、承認待ちは赤の点滅から30秒後に常灯、完了は緑の点滅6秒、エラーは赤の高速点滅。30分イベントがなければ自動消灯する。

Claude Code hooks から HTTP GET で M5Atom Lite の WebServer を叩き、FastLED経由でSK6812を光らせる。Atom LiteはWiFi内蔵でSK6812がオンボードに1粒載っているため、はんだ付けも追加部品も不要。hooksから叩くスクリプトは実質curl 1行。

配属後、技術と自社製品の両方で膨大なインプットに追われていた筆者は、Claude Codeに軽く指示するだけでできるHTML資料を使い始めた。綺麗で情報も整理されており、最初は感動したという。

3日目に問題が出る。綺麗で分かりやすい資料が、そのままスルスルと頭を通り抜けていく。目が滑る、という状態。

そこで、あえてダサいデザインで生成させることにした。分かりやすい資料はスルスル読めてしまうが、読みにくければ流し読みできず一言一句読むことになる、という理屈。結果としてインプットが進み、人に読んでもらうには形はどうあれ資料に魂を込める必要がある、という結論に至っている。

バクラクにはプロダクトを跨いで認可を行いたいケースがある。承認フローを持つバクラク申請と、機微情報を保管する別のサービスXがあり、承認者が承認画面を開くと、まずバクラク申請が承認ルート・承認状態・代理設定から閲覧可否を判定し、次にサービスXのRPCを呼んで実体を取得する。

問題は、「この承認者は見てよい」と判定できるのがバクラク申請側だけである点。サービスX側では承認者が権限を持っていない可能性があるが、業務上はデータ取得を許可する必要がある。

検討した選択肢はいずれも成立しない。サービスXでpermissionを要求しなければIDを指定した直接取得ができてしまい、要求すれば正規の承認画面まで弾かれ、同じ判定をやり直そうにも判定材料がバクラク申請にしかない。この課題がTransaction Tokensの解こうとしているものとほぼ同じだったため、自作実装との差分を調べた、という構成。

e-dashではAWSを全面的にTerraformで管理しており、最近はインフラの構築・運用もAIに任せるようになった。AI登場前は気にならなかったが、手元で迅速にフィードバックループを回せる環境がほしくなった、というのが動機。

ローカルAWSエミュレータは、AWSのAPIと同じレスポンスを手元のプロセスで返し、実アカウントなしにSDK・CLI・Terraformを動かせるようにするもの。2026年7月時点でTerraformから使える主なものが3つ挙げられている。

LocalStackは110以上のサービスに対応するが、無償のCommunity EditionではLambda・S3・DynamoDB・SQS・SNS・IAMなどのコアに限られ、RDSやAPI Gateway、Step Functionsは有償プランが要る。2026年3月以降は無償でも認証トークンの登録が必須になった。Flociは2026年登場のMITライセンスのOSSで68サービス程度に対応し、登録もトークンも不要。Quarkus Native製で起動が約24ミリ秒、アイドル時メモリが約13MiBを公称し、LocalStackと同じ4566番ポートで待ち受ける。

手順は、まずQiita APIのドキュメントを読ませ、次に自分のパブリック投稿をすべてMarkdownで取得させる、というもの。結果として397ファイル、3.91MBが集まった。

そのうえで「私のブログ記事を蒸留し、まるで私が書いたかのようなQiita記事を執筆するスキルを作成してほしい」と指示している。ファイル数が多いため4つのサブエージェントが起動して分析とマージを行い、その後の検証で気づいた点を修正する、という動きになったという。

初回のスキルは微妙に生成AIっぽさが残ったため、検証時のプロンプトをコピーして修正を依頼している。記事冒頭では、この投稿自体は100%人間が書いており、直前に公開した別記事のほうが100%生成AI製である（内容は実検証済み）と明示されている。

Andon Labsが運営する店舗で、AIエージェント「Luna」に3年間のリース契約と10万ドルの予算、会社のクレジットカードを渡し、経営判断を丸ごと任せた実験を紹介している。

Lunaが実際にやったこととして、求人を出して人を雇う、内装業者を探して支払いを済ませる、といった項目が挙げられている。出典はForbesの記事「Welcome To The First-Ever Store Designed, Developed And Run By AI」。

記事はこの実験から、これからの働き方に何を読み取れるかという観点で整理する構成をとっている。

未経験からIT業界を目指す人からよく聞く悩みとして、退職理由をどこまで正直に話してよいか、という点を扱う。人間関係、給与、将来が見えない、といった本当の理由と、「もっと成長できる環境を求めて」という言い換えの間で手が止まる状況を挙げている。

筆者の立場は、伝え方は大切だが、不満があったこと自体をそこまで隠さなくてよい、というもの。採用担当として面接をしていると、退職理由をかなり慎重に話しているのが伝わってくるという。

それより気になるのは「そのとき、どうしていたのか」だとし、「上司が自分の意見を聞いてくれなかったので転職しようと思った」という回答の、その先を聞きたいと書いている。

社内で飛び交う「そこはクラウド側で対応できますね」「AWSに乗せておけば大丈夫です」といったやり取りに、分かったふりでうなずいていた筆者が、思い切って聞いてみたという体裁の記事。

筆者の疑問は、クラウドがネットワークのインフラ系の話なのか、バックエンド寄りの話にも関係あるのか、という点にあった。

「借りる範囲によって呼び方が変わるだけ」と知ったことでモヤモヤが晴れた、という整理を結論に置く。対象読者として、クラウドとインフラの違いを人に説明できる自信がない人、今さら聞くタイミングを逃した人を挙げている。

ある作業を任され、丸一日かけて仕上げて先輩に見せたところ、第一声が「うーん…これじゃないんだよなあ」だった、という場面から始まる。指示通りに作って動いてもいる、という反論も通らない。

筆者が気づいたのは、直すべきだったのは作業の中身より前の段階だったという点。着手前の一手間で手戻りをかなり減らせるようになったとしている。

対象読者として、出来上がってから指摘されるとどこからやり直せばいいか分からなくなる人、完成させることに必死で方向性の確認を後回しにしがちな人、同じ指摘を何度もされて理解力に自信をなくしかけている人を挙げている。