テーマ
テクノロジーの記事
ai_driven_development13
-
並行実行するAIエージェントとTOCTOU — PRのheadを取り直す理由
状態を確認してから使うまでの間に状態が変わる、というTOCTOU(Time-of-check Time-of-use)はファイルシステムだけの問題ではない。同じリポジトリを複数のAIルーティンが並行して触る運用で、レビュー指摘への対応がこの型で衝突した実例と、機械的に確かめて回避した手順を整理する。
-
id属性はallowlistで防げない — DOM Clobberingという名前空間の危険
要素と属性をallowlistで絞っても、id属性だけは別扱いが要る。OWASPが定義するDOM Clobberingの仕組みと、AIが書く説明図に「よくある名前」のidを許してしまい、問い合わせフォームの送信処理が本物のフォームに付かなくなった実例を、実測とともに整理する。
-
テストは「書いた時点」ではなく「壊して赤くなった時点」で完成する — 故障注入を完了条件にする
AIがテストを書く量が増えるほど、「緑である」ことは「検査が効いている」ことを意味しなくなる。わざと欠陥を入れて赤くなるまで確かめる故障注入を完了条件に置いた運用から、実際に素通りした5つの型を実測つきで書く。
-
CI設定を直してもre-runでは効かないことがある — pull_requestイベントが再実行で使うref
GitHub Actionsのpull_requestイベントをre-runしても、直したはずのワークフロー定義が読まれないことがある。公式ドキュメントの記述と、実際に「直したのに赤いまま」を誤診しかけた実例から、re-runとブランチ更新の違いを整理する。
-
構造化データは本文と食い違っても画面に何も出ない — 一致を機械で保つ検査の作り方
JSON-LDは目に見えないので、本文と食い違っても画面には何も現れない。本システムがFAQPageを出すときに実装した双方向の照合と、片方向だけでは何件消えても検出できないかを、実測とともに整理する。
-
Workflow のステップ名は変えてはいけない — Durable Execution の再実行がどう起こるか
Cloudflare Workflows の step.do はステップ名をキャッシュキーとして使う。名前を変えると再実行される仕様と、実際に動いているシステムのステップ構成・リトライ設定を、公式ドキュメントを実際に確認して整理した。
-
AI駆動開発とは何か — Vibe Codingとの違いをどこで引くか
「AIに書かせる」という同じ行為が、個人の実験と業務の開発ではまったく別物になる。Vibe Codingとの違いを、権限・レビュー・監査という運用の仕組みで引く。
-
記事の正本を Git に置く — 公開=マージにすると何が楽になるか
AIに記事を書かせるメディアで CMS を持たず、記事の唯一の正本を Git のファイルに置いた。公開=PRのマージにすると、履歴・レビュー・差し戻しがコードと同じ機構に乗る。実際に運用しているシステムの実装と、失ったもの・まだ繋がっていない部分を公開する。
-
AIの書き込みを後から追えるようにする — before/after/reason の監査ログ設計
AIに書き込み権限を渡すなら、監査ログはあとから足す機能ではなく前提条件になる。実際に運用しているシステムのテーブル定義をそのまま公開し、reason 欄がなぜ必須なのか、何を載せてはいけないのか、バックアップと何が違うのかを整理する。
-
Claudeをクラウドに住まわせてWebサイトを自律運営させてみた
AIエージェントをクラウドに常駐させ、実装・レビュー・執筆・公開までを人手ゼロで回すメディアを実際に組んだ。組織図をcronとツール権限で描く方法、人間の判断回数を減らす判例制度、そして委譲できなかった3つを、稼働中のシステムの実データとともに公開する。
-
LLMアプリのコストを後から説明できるようにする — 計測を一点に集める設計
請求額は分かるのに「何にいくら使ったか」が説明できない。LLMアプリで最も起きやすいこの状態を防ぐには、呼び出し口を1つに絞り、1呼び出し1行を残し、単価をコードに固定しないことが要る。実際に運用しているシステムの実装と、そこで見つかった単価のずれを公開する。
-
AIの書いたものをAIがレビューする — 独立性は「指示」ではなく「ツール権限」で決まる
AIにコードを書かせるならレビューも自動化したくなる。だが同じAIの自己レビューは追認しか返らない。実装役とレビュー役を別セッションに分けた設計と、「レビュー役から書き込みツールを取り上げたつもりで、取り上げられていなかった」という初日の失敗を公開する。
-
自律AIエージェントの実用アーキテクチャ — 権限・監査・緊急停止をどう設計するか
自律AIエージェントを本番で動かすために要るのは、賢いプロンプトではなく「権限・監査・緊急停止」を仕組みで強制する設計である。Cloudflare 上で実際に動いているシステムの実装から、設計判断とハマりどころを公開する。
他ジャンル実証3
-
物流の2024年問題に生成AIは効くのか — 配車と点呼の業務を分解する
物流の2024年問題(時間外労働の上限規制)を配車計画と点呼という2つの業務に分解し、生成AI・自動化に任せられる部分と、人の判断が残る部分を出典つきで整理する。
-
製造現場の検査記録をAIで下書きする — 止めずに試せる範囲の切り出し方
製造現場の検査記録にAIを使うとき、測定値そのものに手を触れさせず、記録の下書きと体裁の整えだけを渡す線引きを、経済産業省の品質不正に関する公表資料を出典に整理する。
-
不動産の物件紹介文をAIに書かせるときに、宅建業法で気をつけること
不動産の物件紹介文を生成AIで作るときに、宅建業法32条の誇大広告禁止と不動産の表示に関する公正競争規約が具体的に何を禁じているかを整理し、AIに任せてよい部分と人が確認すべき部分を分ける。
ai_agents2
-
AIエージェントとは何か — 看護師にもわかる言葉で
「指示を出せば動くAI」と「自分で段取りするAI(エージェント)」の違いを、看護現場の指示出しとリーダー業務の比喩で説明する。
-
医療者のためのAI用語辞典 — LLM・RAG・エージェントを現場の言葉で
医療現場でAIの話をするときに出てくる用語を、看護業務の言葉に置き換えて短く定義する。LLM・ハルシネーション・RAG・ベクトル検索・AIエージェント・ファインチューニングの違いがこれで分かる。
how_ai_works1
-
RAGとは何か — 院内マニュアル検索を例に
院内のルールをAIに「覚えさせる」のではなく「探させる」のがRAGである。仕組みを院内マニュアル検索の例で説明し、導入で実際に詰まるのはモデルではなく資料の状態であることを、現場の実態から整理します。