Claude Haiku 5.5 の登場を機に、Sonnet 以下のモデルで動かしていたサブエージェントの構成を見直した記事。Haiku 5.5 は Haiku シリーズで初めて effort 指定に対応し、単価は Haiku 4.5 の 1/10 になっている。Opus 5.5 / Sonnet 5.5 / Haiku 4.5 などの input・output 料金を Sonnet 比で比較しつつ、サブエージェントをどのモデルに割り当てるかを検討している。
AIエージェント開発をきっかけにLLMの内部構造を理解したいと考えた筆者が、『つくりながら学ぶ！LLM 自作入門』のAttentionやGPT実装でつまずいたため、Transformerブロック1層・attention head 1個・1文字1トークンという最小構成のGPTをClaude Codeと一緒に実装した記録。日本語データ（FineWeb2 Edu Japanese）で学習から生成までを先に動かし、学習ステップごとに生成文が「それっぽく」なっていく様子や、token embeddingを2次元可視化して類似文字が近くに配置される様子を確認している。バイトペアエンコーディングやMulti-Head Attentionを後回しにして全体像を掴む進め方を提案している。
障害対応でログを AI に貼って原因を尋ねる運用が広がる中、AI が有用な回答を返せるかどうかはモデルの性能ではなくログの設計に左右される。断片的なメッセージやコンテキスト不足のログでは原因特定が難しく、リクエスト ID や処理の流れ、エラーの前後関係など、AI が因果関係をたどれる形でログを構造化しておく必要があると指摘する。
育児記録の入力を負担に感じる声を踏まえ、iPhone内で動くAIを使い、話した内容から授乳やおむつの記録を自動で項目分けするアプリ設計を検討した記事。
Claude の自動実行時に、通常実行では出ない権限不足のエラーが発生する現象を扱った記事。原因と対処法を主題としているが、本文で示されているのは「通常実行ではエラーが出ず自動実行でエラーになることがある」という現象の提示にとどまり、具体的な原因や手順の記載は乏しい。
TypeSafe AIが公開した「System One Model」ことJevを実際に試した記事。JevはLLMのように文章を生成せず、こちらが型付きで用意した問いに対して確率やスコアのみを返す点が特徴で、単体では何も起きず、返ってきた数値をどう扱うかは呼び出し側のコードが決める設計になっている。著者は社内問い合わせのエスカレーション先を判定できるかを題材に、バックエンドエンジニアの視点で挙動を確認している。
2026年に登場した TypeSafe AI のモデル「Jev」を題材に、AIエージェントを支えるハーネスの設計がどう変わるかを整理した記事。Jev は文章やコードを長く生成する LLM ではなく、ソフトウェア内で発生する判断を高速に処理するためのモデルとして設計されており、「unstructured state in, typed probabilistic decisions out」、つまり状態を入力すると型付きの確率的な判断を返す点を特徴とする。
Claude Codeが起動時に読み込む記憶の仕組みを、公式ドキュメントと実測をもとに整理。CLAUDE.md・@取り込み・自動メモリの3経路、特に@取り込みの実際の挙動と、大きなプロジェクトの記憶を効率よく読ませる設計パターンを紹介している。
Claude や Codex/ChatGPT、Gemini はコーディングや調査には便利だが、文章作成に使うべきではないという主張。文章を書くこと自体が深く考える工程であり、箇条書きから AI に文書を生成させるとその思考を飛ばしてしまう。AI は文章は得意でも、新しいアイデアを考え出すのは苦手だと指摘する。初稿を書いた後に「この文書を読んでどんな疑問を持つか」「最も重要な点は何か」と質問してフィードバックを得る使い方は有効で、修正や改善を任せるのではなく自分で考えるべきとする。執筆前のデータ整理やパターン発見にも AI は役立つ。
判断特化型AI「Jev」の特徴を具体例で解説。アカウント作成から Playground の使い方まで紹介し、文章に個人情報が含まれるかを実際に判定。従来の LLM と比べた料金や応答速度の違いにも触れる。
Slackの案件スレッドをClaude Coworkに読み込ませ、提案書スライドの作成を3〜5時間から35分へ短縮した運用事例。コンテキスト管理、スライド自動生成、実装手順までを、プリセールス業務をAIに任せる仕組みとして紹介している。
開発環境が「そこで動けば本番でも大丈夫」と思える状態であることの重要性を述べた記事。動くだけでなく、README通りにコマンドを実行してもエラーにならず、必要な構成要素が揃い、資料を大量に読まなくても立ち上げられる環境でなければ、開発環境への信頼が損なわれると指摘している。
筆者がキャリア初期にシェルスクリプトを扱えず、コマンドを一つずつ手で実行するだけだった経験を振り返る記事。条件分岐・ループ・並列実行・パイプといった「既存のプログラムを組み合わせて目的を達成する」手段としてのシェルを学んだことが転機だったと述べ、GUI 頼みのエンジニアは GUI が想定していない処理で行き詰まりやすいと指摘する。CI やデプロイ、検証ロジックの多くが Bash/Zsh で書かれている以上、ツールが書かれた言語を読めないと改善もできないとして、シェルを学ぶ価値を説く。
近年のAIモデル発表はパラメータ数やベンチマーク、推論速度を競うLLMの新バージョンが中心となっているが、本記事は文字列生成を捨てたというTypeSafe AI「Jev」を取り上げ、LLMとは異なるアーキテクチャのAIがなぜその設計を選んだのかを解説する。
文章生成ではなく高速な「判断」の出力に特化したAIモデル Jev のクイックスタート。基本構造は State → Questions → Typed Decisions で、状態と質問を渡すと型付きの確率的な判断を返す。複数の質問を並列評価できる設計で高速化を実現しており、判断の型として Choice・Score・Noul の3種類を用いて質問を定義する。
AIがコードを書く時代には、実行時オーバーヘッドがなく可搬性の高いC言語が再び主流になるというSNS上の言説を検証する記事。高水準言語は人間の生産性のために性能を犠牲にしてきた、AIはメモリ管理を誤らない、安全性はAI自身が検証できる、といった前提を一次資料に当たりながら一つずつ検討している。
GitHub Podcast のエピソードをもとに、AI に関するよくある「過激な主張（ホットテイク）」を噛み砕いて検討する内容。①AI 生成コードも読むべきで、リスクの高い箇所に応じてレビューの深さを変え、説明と責任を持てるまで確認するのが実際のスキルであること、②採用では AI を使うか否かより、いつ使い・どうレビューし・どこで人を介在させるかという判断力が問われること、③Skills は MCP を置き換えるものではなく、MCP がツールやデータへの標準的なアクセスを提供し、Skills がプロセスや規約といった文脈をパッケージ化するもので、両者は補完関係にあること、④RAG は廃れたわけではなく、モデル外部の知識を取り込む手段として依然重要であり、検索が不十分だとトークン浪費や回答の不完全さを招くこと、などを議論している。
コーディングエージェントの性能を左右するハーネス設計を、計画・行動空間・コンテキスト管理の3要素に分解して実証的に比較した論文。SWE-Bench Verified と Terminal-Bench 2.1 で4モデル・176設定を評価し、コンテキスト管理は予算が厳しいほど有効で、主な効果はオーバーフロー防止にあること、LLM要約の前にルールベースの省略を行うのが最も効率的であること、計画は弱いモデルでは精度の足場、強いモデルではコスト削減になること、bashに強いモデルはbashのみのインターフェースでも低コストで動けることなどを報告している。
Jev に触発された OpenJev の実装を読み比べ、既存モデルの点数を直接読む方式と、判断用に学習し直す方式の違いを整理した記事。生成しない AI の代替設計を考える内容。
AIエージェントに実装を任せるようになりPRやテストコードが増加、CIの稼働時間が問題化した。CIの目的を維持したまま3つの対応を行い、1runあたりの稼働時間を144分から39分へ73%削減した事例を紹介する。
AIエージェントに実装を任せることでPRやテストコードが増え、CIの稼働時間が増大した問題に対し、CIの目的を維持したまま3つの対応を行い、1runあたり144分から39分（73%削減）まで短縮した取り組みの紹介。
エージェントはゲームの一発生成や大規模なマイグレーションをこなせるようになったが、実際のソフトウェア開発の大部分は依然として人間のエンジニアが主導している。多くの組織が大量のトークンをエージェントに投じたものの成果は芳しくなく、幻滅期に入っている。次の段階では、エンジニアの価値は「良いアイデアを出すこと」と「適切なアーキテクチャを設計すること」に移り、バグの検出と修正、本番エラーのデバッグとパッチ適用、エージェント用プロンプトの最適化、フロントエンドの一貫性維持といった作業はエージェントに任せるべき領域として挙げられる。そのためにはループやガードレール、評価基盤など新しいプリミティブの整備が必要になる。
Jevは文章や業務データを読み取り、分類・採点・条件判定の結果を確率付きで返すAIモデル。返り値はソフトウェアの条件分岐に利用することを想定しており、プログラムが明確に判定して複雑な制御に応用できる点が特徴。本記事はJevの概要を、従来型LLMやAIエージェントとの違いという観点から整理して解説する。
AIがコードを書くようになり「認知負債」が課題として認識されつつある一方、そもそも人間が全てを認知すべきなのかという議論もある。本記事は「技術的負債に向き合うConference 2026」の聴講を踏まえ、認知負債を「仕組みを人間が認知しないまま稼働しているコードが存在すること」と定義し、その問題点を考察する。
筆者が約1年半にわたり個人の開発で育ててきたAI開発フローについて、Claude Codeを実務に取り入れ、サブエージェントによる思考レビューなど試行錯誤を経て現在の形に至るまでの変化を紹介する。
Claude Code などのコーディングエージェントにより一人でフロントから運用まで組めるようになった一方、ハッカソンで最初に悩んだのは「何を作るか」だった。AIハッカソンで優勝した経験を基に、アイデアの出し方を述べる記事。
OpenSpec はソフトウェア仕様の作成・管理のための軽量で設定可能なフレームワーク。作りたいものを spec として記述し、チームとコーディングエージェントの認識を揃えながら、要件の洗練、仕様が正しい対象を記述しているかの検証、実装が仕様に一致するかの確認を行う。Claude Code、Codex、Cursor、GitHub Copilot、Gemini CLI など多数のツールと互換で、explore / propose / apply / verify / archive というワークフローコマンドを提供する。
生成AIを業務に組み込む際、生成→評価→実行の流れでは、実行しないと評価情報が得られない処理に対応できない。実行を段階的に許可し、何を観測し、その結果から次の実行範囲をどう判断するかというHuman-in-the-loopのゲート設計の必要性を論じている。
業務・完了条件・役割・受け渡し・並列化・検収・自律度・学びの蓄積を一続きで扱う、マルチエージェントによるAI開発チームの設計書。図解に加え、TypeScript製タスク管理アプリへの機能追加をCodexの実装と既設のClaudeレビューCIで実走し、仕様・差分・テスト・AIレビューをつなぐ方法を示す。並列構成の提案や未計測の効果は実走の結果と区別して扱っている。
個人開発の記録ツールにLLMでWikiを書かせる取り組みを半年続けた経験談。RSSリーダーやクリップ、バレットジャーナルなどに溜まった記録を活用するため、全文検索やタグ付けだけでなくLLMによるWiki生成を試したが、最も役立った画面はLLMが生成した文章をそのまま使うものではなかったという内容。
シンプレクスが全社展開する「AI-Native Delivery」の取り組みの一環として、開発ライフサイクル全体（要求整理・設計・実装・テスト・運用）を人間とAIの役割から再設計するAI-DLCの導入により、チームの開発プロセスがどう変わり始めたかをエンジニアが報告する記事。
Claude Code や Antigravity などの AI エージェントを使ったスポーツ予測・分析システム開発（270コミット、73 PR）で発行された延べ542件のプロンプトを調査し、指示の出し方と事前調査の有無が手戻り・バグ・CI/CDエラー・トークン消費に与えた影響を5パターンに分類した分析レポート。①明確・迅速完結型(51.1%)、②不明瞭・確認過多型(20.5%)、③不明瞭・バグ誘発型(16.6%)、④リファレンス不足によるCI/CDエラー型(10.3%)、⑤指示は明確だがAI側の影響範囲確認不足型(1.5%)。プロンプト改善で減らせる問題(③④)とAI側の検証ルールで防ぐべき問題(⑤)を区別すべきとし、プロジェクトのゴール定義や作業環境（モバイルかPCか）も成果に影響すると指摘している。
自作の Claude Code スキル47本を1ヶ月ほど運用して測定した記録。スキルは入れるだけなら簡単だが、数を増やすほど呼ばれなくなるという結果が得られたという。重くなるからではなく、登録したスキルの説明文が互いに競合し合うことが原因だと述べている。スキル設計・運用の知見を7つの観点でまとめている。
バイブコーディングで複雑化し制御不能になった GUI アプリに対し、AI へそのまま渡せる対策プロンプトを提示する記事。全コンポーネントを Root 配下に置き、各コンポーネントを MVP パターンの Passive View として描画パラメータのみ操作させ、動作は Chain of Responsibility でイベントをバブリングしてステートマシンとして振る舞う Mediator に裁定させる、という構造を指示する。macOS 常駐型 AI アシスタント「CooSenpAI」の開発経験を踏まえた内容。
Claude Code の `/goal` コマンドは、与えた条件を別のモデルが評価者として判定し、満たされるまでループを回す仕組み。本記事では終了条件の書き方によって評価者が正しく判定できるかを、7 通りの条件で検証した結果を報告している。
Yahoo!検索のフロントエンドエンジニアが、個人で使っていた Coding Agent による開発自動化をチーム全体の取り組みへ広げるまでの実践を紹介する記事。エージェント導入の進め方やチーム展開の工夫が語られている。
Difyの開発元LangGeniusの日本法人、パーソルクロステクノロジー、JTPの3社が、Difyエンジニアの育成と企業現場でのAIエージェント導入・内製化支援を共同で開始すると発表した。パーソルクロステクノロジーが人材基盤から候補者を選出し、JTPがDify導入・運用の研修を実施、今後100名の育成を目指す。背景には、現場の業務知識とAIアプリケーションの開発・運用知識を併せ持つ人材の不足があり、ツール導入後の継続的な改善・運用を担う人材と体制の整備が課題だとしている。ただし研修期間や内容、認定の仕組みなどの具体は未公表で、実態は人材派遣・SES事業の延長線上にある。
AI コードレビュー製品 Entelligence によるベンチマーク比較。公開 PR 50 件（Cal.com、Sentry、Discourse、Keycloak、Grafana から各 10 件）に対し、格安な GPT-5.6 Luna と高価な GPT-6 Astra を同一プロンプトで実行。Luna は検証済みバグ 69 件・精度 74%・50 PR で $0.20、Astra は 92 件・精度 96%・$5.66 で、検証済みバグあたりコストは $0.0030 対 $0.061。Luna は誤検出が多く、セキュリティバグの検出は 24 件中 9 件（Astra は 19 件）。日常的な正当性バグの検出には安価なモデルで十分だが、認証・権限まわりのコードを単独でレビューさせるのは避けるべきという結論。
AIエージェントの文脈で頻出する「オントロジー」について解説した記事。元は哲学の存在論だが、現在はAIエージェントが理解・共有できる形式の設計図として解釈されることが多い。オントロジーとは何か、なぜAI駆動開発に必要なのかを説明している。
Meta の個人向け AI エージェント Muse の実行基盤をブラックボックス的に調査した記事。著者のセッションで subagent.spawn を使い 120 個のサブエージェントを一斉起動したところ、33 個だけが生成に成功し 87 個が同一のデータベースエラーで失敗、集約結果は返らず親は running のままなのに子 33 個はすべて completed として永続化される不整合が観測された。ランタイムが PostgreSQL に書き残した agent.agents や agent.subagent_spawns、進捗テーブル、コンテキストストアといった記録から、サブエージェントのファンアウト、永続状態、負荷時の spawn 経路を再構成している。モデル文字列 ipnext/avocado-5.16-v4 などの観測事実と推測の区別、アクセス範囲の限定も明記される。
Linux Foundation傘下のAgentic AI Foundation（AAIF）は、オープンソースのEnvoy AI GatewayプロジェクトがAAIFに加盟し、「Agent Router」へ名称変更したと発表した。OpenAIやAnthropicなどAIベンダごとに異なるAPIを吸収・統合し、MCPやAGENTS.md、Agent2AgentプロトコルなどAIエージェント関連技術の標準化を進める狙い。
基盤モデルの仕組みと、その技術スタックがどう進化してきたか、実システムに適用したときのトレードオフを扱う技術書の紹介。対象読者は、API 利用の表面的な理解を超えて、アーキテクチャ、学習パイプライン、推論システム、検索スタック、評価ループ、エージェント的ワークフローのmental model を築きたい AI エンジニアや研究志向の読者。attention、MoE、RLHF、マルチモーダル、長文脈の推論配信、RAG、エージェントといった話題を、歴史的流れ・数理的アイデア・システム制約の観点から一つのエンジニアリングの物語として結びつけることを狙う。PyTorch の概念的なサンプルコード、小テスト、対話的な可視化を含み、品質・メモリ・スループット・レイテンシ・スケーリング・アラインメントのトレードオフを考える力を養う。初学者向けの入門書ではなく、継続的に更新される living document として運用される。
フロントエンド開発において、要件定義から実装・テストまで責務を同じ語彙（Subject Object Verb）で記述し、ymlやアノテーションで静的に解析する提案。仕様と実装の突合をCIで継続的に検証し、要件漏れや実装漏れを減らし、AIの品質ゲートにも活用できるとする。
Web アプリ向けの必須 UI トランジション（カードリサイズ、数値のポップイン、モーダル開閉、タブのスライド、スケルトンローダーなど）を集めたコレクション。コピー＆ペーストで使えるほか、coding agent から skill 経由で利用できる形で提供されている。各トランジションには動きの説明が付き、Pro 版や微調整ツールも用意されている。
Claude Code on Bedrock の auto mode を起動時デフォルトに設定した際の挙動を、対応モデルと非対応モデルで比較した記事。具体的な設定方法や差分の詳細にはほとんど触れておらず、挙動が分かれるという結果の報告にとどまる。
モデルを差し替え可能なコーディングエージェントのハーネスとして OpenCode・pi・DeepSeek Harness の3つを取り上げ、それぞれの設計思想と動作の違いを比較する。同一モデルに接続して同じ課題を解かせることで、ハーネス選択の根拠を整理することを目的としている。
前回公開した「トークンを節約してレビューをローカルLLMに任せる」構成について、読者コメントで指摘された設計上の穴を確認したところ事実だったため訂正する記事。公開したModelfileは実際には著者の環境で動いておらず、Ollamaの/api/chatはmessages内のsystemロールを扱う仕様になっているため、想定した構成が成立していなかったことを説明している。同じ構成を組んだ読者が同じ問題を踏まないよう、まず誤りの内容を明示している。
LINEアプリ開発SBUのAIディベロッパーエクスペリエンスユニットによる記事。AndroidとiOSの開発者が混在するチーム体制で、AIが生成した成果物を人間の開発者がどう受け取り、レビューし、設計に組み込んでいくかというワークフローの設計について述べている。
ShopifyがReact NativeからSwift/Kotlinによるネイティブ開発へ回帰する方針を示したことを受け、クロスプラットフォーム開発が解決できるコストと解決できないコストを整理した記事。技術選定のトレードオフを考える材料になる。
機密文書やプライバシーに関わるテキストを翻訳する際、Google 翻訳や DeepL などのクラウドサービスは使いたくないが、ローカル翻訳は LLM 実行による高負荷か低品質かの両極端になりがち。そこで Firefox に標準搭載されているローカル翻訳機能に着目し、about:translations を使って手軽に低負荷かつ実用品質の翻訳を行う方法をまとめている。