横浜で開催された KubeCon + CloudNativeCon Japan 2026 に参加してきました。本編は 2 日間の日程で、その前日にはコホストイベントが開かれています。私が参加できたのは前日のコホストイベントと本編 1 日目で、2 日目は私用のため参加できませんでした。Kubernetes は大規模トラフィックに柔軟性が求められる組織のためのツールであり、NASEBANAL のような駆け出しのアプリ開発とは無縁——参加前の私はそう考えていました。ですが会場での議論からは、むしろ自分の事業に直結するインサイトが得られました。本稿では特に学びの大きかった 4 点——テスト実行環境（Harness）としての Kubernetes、エージェントに何を期待するのかというアーキテクチャの議論、NVIDIA が示した障害時のルートコーズ調査へのエージェント活用、そして Cast AI と Kimchi が語ったエージェント利用そのものの FinOps——を、NASEBANAL との関連づけとともに振り返ります。
続きを読む →前回のブログの最後で「次のステップはモバイル」とお伝えしたとおり、NASEBANAL Growth Mobile を目下開発中です。Target・Recorder・Stopwatch を 1 つのクライアントに束ねたこのアプリは、既存の Web 版 UI をベースに、Claude Code から Figma MCP を用いて画面を設計し、Figma のスクリーンイメージを微調整したうえで、その画面と OpenAPI Spec をもとに自動生成しています。あわせて、モバイルではほぼ手間なく実装できたダークモードを Web アプリにも展開しました。UI 基盤とデザイントークン（UI のカラーパレット）をまとめた共通コンポーネントと、API スペックを共有パッケージとして切り出しているため、これも軽い変更で済んでいます。最後に、この一連の流れこそ、いま内製化支援で考えているアプローチそのものである、というお話をします。
続きを読む →前回のブログで「次回くわしく」とお約束した Contract-Driven Development (CDD) の取り組みについて、改めて整理してご紹介します。なぜ仕様の明確化と品質担保の両立に CDD が効くのか、CDD の代表格である Pact ではなく Specmatic を選んだ理由（Consumer-Driven の制約と、OpenAPI Spec を契約とするアプローチの相性）、そして実際に NASEBANAL の Spec・バックエンド・フロントエンドを一巡させて試したパイプラインと、そこから得た学びをまとめます。内製・外注・AI エージェントが共存するこれからの開発で、OpenAPI Spec を共通のガードレールに据えるという仮説の現在地です。
続きを読む →開発者向けサイト [NASEBANAL API Specs](https://api-specs.nasebanal.com/ja) の公開にあわせ、その背景にある問題意識と直近の取り組みをご紹介します。AI コーディングによって機能の実装は加速する一方、実装の理解が追いつかず、各 PR・Merge を経てコードがどのような状態になったのかが見えにくくなりがちです。本稿では、この『開発の状態を見えるようにする』という課題に対して進めている 2 つの取り組み——API リファレンスの別サイト化を起点とした Contract-Driven Development (CDD) への布石と、DORA / Code メトリクスおよびトークン消費による開発の可視化——を整理し、内製・外注・エージェントが共存するこれからの開発における OpenAPI Spec の役割についても考察します。
続きを読む →なぜ汎用的なデータ記録ツールを作ったのか。Tokenization的発想のセキュリティ、事前定義カテゴリタグ、OGP画像付きSNS共有について。
続きを読む →