最終回です。生成が成功したあとに何をしたか、という話をします。slide-forge の共通契約に、たった 1 行こう書かれています。API success is not visual QA.（API の成功は、視覚 QA ではない）この 1 行のために、今回 5 件の欠陥が見つかりました。 1. 検査は 2 段構えGate 1（オフライン）Gate 2（視覚 QA）いつ生成前生成後何を見る座標・文字量・重なりの計算サムネイル画像コストAPI を呼ばない（無料）画像を読むコマンド--dry-run --strict...

はじめに初現場にアサインされて7ヶ月経ちました。今、少しずつKubernetesやTerraformを触れるようになっています。ひとつひとつの構築記録はそれぞれの記事に書いてきたので、今回は「どうやって覚えたのか」を振り返ってみます。先に書いておくと、まだ分からないことだらけです。 test と staging を作ったところまでで、本番の運用はしていません。なのでこの記事は「こうするのが良いです」という話ではなく、私がつまずいた記録として読んでもらえると嬉しいです。というのも、「Kubernetes の勉強についてブログを書いてみたら？」と言われたのですが、私は勉強時間...

LLM に営業資料を作らせるとき、いちばん怖いのは価格です。もっともらしい金額を自信満々に書いてきます。ここをどう封じたか、という回です。 1. 価格の一次情報を「場所」で縛るslide-forge の Scalar 系スキルには共通の契約があります。okf-bundle.md を、Scalar 製品の事実（機能・エディション・バージョン・リリース状態）と価格・課金モデル・Pod の数え方の第一情報源とする。能力・エディション境界・数値を記憶で書かない。OKF バンドル（OKF-ScalarDB-ScalarDL）はScalarDB / ScalarDL の公式ド...

最終回です。この連載で何度も出てきた問題に、最後にまとめて答えを出します。同じロジックが TypeScript と Java に 2 本ある。式エンジン（JEXL）— ブラウザのプレビュー用と、サーバの PDF 出力用数値・日付フォーマッタ — 同上要素タイプの一覧 — フロントのレジストリと、サーバのレンダラー登録スキーマの検証 — TypeScript の型と、Zod スキーマ定数 — 識別子の正規表現、システムグループ名、mm→pt の換算これが一度でもずれると、プレビューと PDF が違うものを出します。第 5 回で潰した 40 件の多くは、突き詰めればこの構...

ここまでの記録がようやく提案書になります。ただし「議事録を要約してスライドにする」のではなく、課題解決型提案の型に、確度つきの事実を流し込むという作り方です。 1. 型は 17 セクションで決まっているreferences/scalar/proposal-map.ja.md §2 に、セクションとその根拠が並んでいます。#セクション根拠1エグゼクティブサマリ決裁者は冒頭しか読まない。結論先出し2背景と現状課題認識の合意形成を解決策より先に3課題の整理（3 点）課題は 3 点まで4課題の構造対症療法との差別化の土台5...

第 2 期の 10 日間で、Issue は 235 件立って 235 件閉じました。日別に見るとこうです。日起票クローズ07-16131307-17313107-18411707-19403407-20305507-21181807-23273107-2434347 月 20 日、1 日で 55 件。今回はこの処理の仕方の話です。 1. 60 件が同時に開いている状態7 月 19 日に一斉に立った Issue #197〜#226 の 30 件は、分野ごとにきれいに固まってい...

このプロジェクトで一番長く戦ったのは、機能追加ではなく 「同じテンプレートから、ブラウザのプレビューとサーバの PDF が別のものを出す」 という問題でした。対応した Issue は 40 件を超え、7 月 16 日から 7 月 23 日まで断続的に続いています。今回はその 8 日間の記録です。 1. 24 要素中 18 種が、無警告で空だったこの Epic は、7 月 16 日の朝 5 時に打った 1 行から始まっています。この配下のコードをレビューし、レポートをデザインし、帳票を出力するエンジンを作るための Issue を作成してください。返ってきたのが Epi...

第 1 期の最後のコミットは 2026-05-02。次のコミットは 2026-07-16 です。その間 75 日、コミットはゼロ。ただし、まったく触っていなかったわけではありませんでした。セッションログには 5/8・5/11・5/14・5/20 の 4 日分、こういうプロンプトが残っています。2026-05-08 06:55 起動してください2026-05-08 07:06 storybook を起動してください2026-05-11 07:55 storybook と dev を起動してください2026-05-14 04:19 きどうしてください2026-05-2...

前回（ブレスト55本と計画書61本）は「これから作るもの」の管理でした。今回は 「作ったものへの指摘」 の管理です。リポジトリのルートに todos/ というディレクトリがあります。中身は Markdown が 280 枚。todos/001-complete-p1-prototype-pollution-resolve-field.mdtodos/002-complete-p1-unvalidated-image-src-xss.mdtodos/003-complete-p1-store-mutation-during-render.md...todos/280-pend...

前回（全体像と3つの期）で、第 1 期の 15 日間には Issue が 1 件も無かったと書きました。では何で作業を管理していたのか。Markdown 2 種類です。docs/brainstorms/ 55 本 設計の議論と、決めたことの理由docs/plans/ 61 本 実装計画（feat 49 / fix 7 / refactor 5）この回は、この 2 つのフォーマットの話だけをします。 1. リポジトリより 1 日早い文書docs/brainstorms/ の最も古い 5 本は 2026-04-05 の日付です。リポジトリの ini...

帳票をドラッグ&ドロップで設計して、サーバ側でベクター PDF を出すアプリケーションをClaude Code と作りました。稼働日は 25 日、コミット 635、PR 257、Issue 235。この連載は「何を作ったか」ではなく 「どう進めたか」 の記録です。リポジトリの Issue・PR・docs/ に加えて、私が実際に打った 387 行のプロンプトもセッションログから掘り起こして突き合わせました。第 1 回では、全体の数字と、途中で 1 回だけ大きく変わった進め方の話をします。リポジトリはこれです。https://github.com/wfukatsu/re...

ここまでで作った記録を 1 つの台帳（account.json）に集約します。この台帳が正本で、活動計画デッキ 10 枚はその描画結果です。デッキは一度も直接編集しません。 1. 台帳のかたちaccount.json はこういう構造をしています。{ "meta": { "stage": 3, "forecast": "Best", "amount": "...", "closeDate": "2027-02-28" }, "facts": [ { "date": "...", "kind": "said|observed|assumed", "who...

この連載でいちばん書きたかったのがこの回です。AI が、自社製品が顧客環境に対応していないことを見つけ、それを提案書の懸念スライドの筆頭に置きました。 隠すという選択肢が設計に入っていなかったからです。 1. 製品適合の判定は「別ファイル」でやるヒアリングシートは製品非依存です。顧客の事実だけを聞き、「ScalarDB が使えるか」の判定は持ちません。判定は製品ごとの補遺（templates/sales/products/scalar.ja.md）が持ちます。分担はこうです。hearing.json 顧客の事実（製品の話は書かない） ...

架空の顧客 1 社を立てて、議事録の整理から提案書・見積の納品まで、B2B 営業のプロセスをAI エージェントに一周させました。この回では何を作ったかと、なぜその順番なのかを先に置きます。 1. 作ったもの指示は 1 行でした。あなたは Scalar の営業です。仮想の顧客を想定して、スキルをフル活用して、プロセスを進めてください。結果は、Google Drive 上にフォルダを作成して、そこに保存してください。出てきたのは 21 ファイルです。フォルダ成果物枚数・形式00_活動計画活動計画デッキ（URL 不変で更新）／ account.js...

本記事は、弊社CTO山田の「Architecture in the AI Era」シリーズ Part 2 の日本語訳です。原文：https://www.linkedin.com/pulse/more-free-lunch-consistency-across-services-hiroyuki-yamada-a5ilc/訳は筆者（投稿者）によるものです。誤訳や不自然な点があればご指摘ください。今回は「AI時代のアーキテクチャ」シリーズ 第2回である。（第1回では、AIがシステムをマイクロサービスに分割すべきタイミングを変えつつあると論じた。）シングルデータベースの内部の一貫性は...

今回は、CLAUDE.md、Skills、Hooks、判断チェックリスト —— を Claude Code のプラグインとして束ね、社内に配布する方法を扱います。 背景・目的 AI駆動開発による内製化の成果物は「動くシステム」ではない「動くシステム」を成果物にすると、システムのリリースと同時に学習が止まります。参加した数名の中に知見が残るだけで、組織には残りません。そこで最終成果物を 「自社専用の Claude Code プラグイン」 に置くことが重要です。要件は1つです。プログラムに参加していない社内メンバーが、インストールして使えることこの要件があると、途中の活動...

素材は議事録 3 本とメール 1 通でした。ここから提案書に至るまでに、一度も「議事録から直接スライドを書く」ことをしていません。間に「確度つきの事実の器」を挟みます。この回はその話です。 1. 入力にした素材架空の商談として、こういう素材を用意しました。out/sim-input/ 2026-06-18_初回訪問議事録.md DX推進部長との初回接点 2026-07-09_技術ディスカバリー議事録.md 現行 5 サブシステム、要件 4 点の受領 2026-08-06_デモ報告と社内展開_議事録.md 決裁者が同席、PoC 成功基準 4 点を合...

この記事では、レビュー指摘がどれだけ仕組みに変換されたかを測る指標 —— 資産化率 —— の定義と、その運用方法を扱います。AI駆動開発を続けていると、レビュー指摘は際限なく増えます。しかしその指摘を「毎回言う」ままにしていると、Middle Loop の負荷は永遠に下がりません。かといって、すべての指摘を資産化するのも誤りです。1回きりの指摘まで全部ルール化すると、資産そのものが保守の負債になります。 背景・目的 なぜ「模範を配る」ことに意味があるのかAI駆動開発の実態について、興味深い調査結果がいくつか出ています。AIが生成したコードの重複は増える傾向にあり、リファ...

!⚠️ ご注意（記事の前提条件）本記事で紹介している設計案やコード例は、設計検討段階の調査に基づくものです。実際の運用環境で稼働しているコードそのものではないため、実装の際はご自身の環境に合わせて適宜調整してください。https://zenn.dev/scalar_sol_blog/articles/aae32e93fd5680https://zenn.dev/scalar_sol_blog/articles/4daac176cb2777前編・中編では、Kyvernoの最新仕様（CEL移行）や「誰が所有するか」で分ける設計の軸、導入プロセスを調べて整理しました。この記事単体...

本記事は、弊社CTO山田の「Architecture in the AI Era」シリーズ Part 1 の日本語訳です。原文：https://www.linkedin.com/pulse/start-monolith-good-advice-ai-changing-hiroyuki-yamada-ou58c/訳は筆者（投稿者）によるものです。誤訳や不自然な点があればご指摘ください。「AI時代のアーキテクチャ」シリーズの第1回は、”AIはシステム構築のあり方をどう変えつつあるか”である。「早まってマイクロサービスに飛びつくな、モノリスから始めろ」ここ10年の大半、これは正しいと...