最近、AIを使ったプロダクトをAIを使って開発している中で、プロンプトの管理をどうするのがいいのか、ずっと考えている。しかも、似たような問題に全く別の2つのプロダクトで同時にぶつかっていて、なかなか答えが出ない。ただ、考えているうちに、これは単に「プロンプトをどこに保存するか」という話ではなさそうだと思うようになった。むしろ、専門家が持っている判断基準や会話の進め方を、どうやってAIプロダクトの中に受け渡すのか、という話に近いと言える。 正直まだ結論はない。ただ、現時点での仮説としては、プロンプト本文だけを管理しても足りない。モデル、パラメータ、システムプロンプト、セッション間のハンドオフ、評価、バージョン管理まで含めて、専門家とエンジニアが一緒に触れる場所が必要なのではないか、という気がしている。整理がてらそんな話を書く。みんなどうしてるのかも気になるテーマなので。 どういうプロダクトを

少し前に生成AIでSaaSが終わる、という話をよく目にした。というか今でもよく聞く。「SaaS is Dead」というフレーズで語られたりもするし、AI市場全体の今後を予測する文脈で出てくることもある。 ただ、自分の周りで実際に起きていることを並べて眺めてみると、それほど単純な絵にはならない。市場のどこが本当に変わって、どこは変わらないのか、昨日そんな話をしたので書く。 消費者向けのSaaSは当面なくならない 僕は「これからは誰もが自分でツールを作る時代だ」とは思っていない。そもそも「自分で何かを作る」ことに興味のある人は、世の中において多数派ではないのだ。 例えば僕が開発に関与している『Speech Link』という失語症リハビリ支援アプリがある。ユーザーは失語症の当事者やその家族・支援者で、決して大きな市場ではない。この領域で「生成AIを使って自分でリハビリツールを作る人」が出てくるか

クラウドネイティブ会議2026 1日目に発表した資料です

メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、AWS

CI/CDシリーズの5本目、これで最終回。1本目はデプロイパイプラインの土台、2本目はPRごとのプレビュー環境、3本目はDB操作のワークフロー化、前回はAI並列開発でのコンフリクト自動解消について書いた。 今回は地味な話。 背景 開発しているプロダクトの機能が増えるにつれて、Stripe決済やGoogle Calendar連携といった外部サービスとの統合が必要になってきた。 これらは単にアプリケーションコードを足すだけでは済まなくて、デプロイパイプライン側にも影響が出る。新しいシークレットの管理が主要なところになる。最初から全部入りで組んでおけば良かったのかもしれないが、必要になってから差し込むのが普通だと思うので、そういう前提でやっていく。 条件付きシークレット注入 StripeやGoogle Calendarやメールで使うResendなどのシークレットは、すべての環境で必須というわけで

最近、LinkedInプロフィールの英語版を整えていて、その中で「Fractional CTO」という単語に出会った。スピーチリンク株式会社での自分の関わり方を英語で表現するときに出てきた言葉で、僕はこの単語を知らなかったのですぐにググって、「へー、なるほど。そういう概念があるのか」と思った。 その時の感想としては肯定派でも否定派でもなくて、ふーんという感じだった。だが改めて考えてみると、自分の中で引っかかるものがある。今回はそれを整理してみる。きっと賛否ある。 フラクショナルCTOとは 調べた範囲だと、フラクショナルCTOというのはざっくり「CTOレベルの関与を、必要な期間・必要な分量だけ提供する」という形態らしい。フルタイムでCTOを雇うほどではない、もしくは雇えないが、CTOクラスの判断や関与は必要な企業向け、という文脈で語られていることが多い。 日本だと近い概念として「技術顧問」「

CI/CDシリーズの4本目。1本目はデプロイパイプラインの土台、2本目はPRごとのプレビュー環境、前回はDB操作のワークフロー化について書いた。今回はAIエージェント（Devin、Claude）による並列開発で発生するコンフリクトの自動解消について。 背景: AIエージェント並列開発のコンフリクト問題 普段、DevinとClaudeを使った並列開発をしているので複数のAIエージェントが同時にPRを作成・更新するわけだが、その結果コンフリクトが頻発するようになった。 これはある意味で構造的に避けられない問題で、devブランチにPRがマージされるたびに他のオープンPRとの間でコンフリクトが生じる可能性がある。人間が1人で開発しているならPRは基本的に直列だし、複数人でもAIと比べると圧倒的に実装速度が遅いからレビューしたりマージする側にも余裕があって結果的に問題になりにくい。でもAIエージェン

CI/CDシリーズ: 1本目: Next.js + NestJSのモノレポでGitHub Actionsのデプロイパイプラインを構築した 2本目: Pull Requestごとにバックエンドも含めたプレビュー環境を自動構築する仕組みを作った 3本目: GitHub ActionsとECS Run TaskでDB操作を自動化する（この記事） CI/CDシリーズの3本目。今回はデプロイ以外の運用自動化、具体的にはDB操作のワークフロー化の話。 背景: なぜ運用タスクをワークフロー化するのか デプロイ以外にも繰り返し発生する運用タスクがある。マイグレーションの適用、マスタデータの投入、テストデータの投入、データパッチの適用など。 これらを手動でSSHやローカルからDB接続して作業する運用はセキュリティ的にちょっと厳しいところ。それにVPC内のリソースへのアクセスにも制約がある。今回はAurora

個人事業主や法人はとにかくバックオフィス業務が多いです。 経理・会計だと SaaSの請求書（領収書）を毎月集める クレジットカード明細と領収書を突合する 取引先へ請求書を発行する 入金された振込と自分が発行した請求書を突合する freeeに仕訳を切る 決算期に税理士さんに資料を渡す 法人税・消費税・地方税の申告対応（税理士経由） 資金調達・財務だと 信用金庫や日本政策金融公庫からの借入を管理する 借入の返済スケジュールを管理する 資金繰り表の更新 労務・社会保険だと 社会保険（健康保険・厚生年金）の加入手続き・届出 役員報酬の変更手続き（定時株主総会の議事録作成含む） 算定基礎届の提出 労働保険の年度更新 年末調整の対応 住民税の特別徴収の処理 補助金・助成金だと 補助金・助成金の申請書類の作成 交付決定後の実績報告書の作成 証拠書類（見積書・発注書・納品書・請求書・振込明細）の保管 報告

Twilog MCPというリモートMCPサーバーがある。自分の過去ツイートを検索したりできるやつで、Togetterが提供している。これをClaudeで使いたかったんだが上手く行かなかった。 TwilogのMCPを久しぶりに使おうと思ったらMCPサーバーに接続できないって言われるんだが— Keisuke Nishitani (@Keisuke69) 2026年4月18日 ヘルプにしたがってインストールしようとしてもできない。どうやらNode.jsが必要みたいだ。以前はCursorにインストールして使ったことがあったのだがこのときはDevContainerのNode.jsがあったので問題にならなかった。 そういうことか。TwilogのMCPって固定Bearerトークンしかないからmcp-remoteを挟んでるからローカルにNode.js必要なのか https://t.co/QodmavvLk

前回、GitHub Actionsを使ったCI/CDパイプラインの仕組みを作ったという話を書いたが、今回はPull Request（PR）ごとのプレビュー環境を構築したのでそれについて。 課題 フロントエンドのプレビュー環境はVercelが勝手にやってくれるので何も困らない。PRを作ればプレビューURLが払い出されてそこで確認できる。問題はバックエンドだ。 今回のプロジェクトの場合、PRは機能単位で作成されるのでフロントエンドとバックエンドの両方に修正が入ることが普通にある。フロントだけプレビューできてもバックエンドがdev環境のままだと、API側の変更を含む修正の確認ができない。 しかも同時に複数のPRが開かれてそれぞれレビューされるのもよくある。生成AIを大活用するようにした結果10とか20のタスクを並列で実行させるので、それらがPRとしても同時に並ぶ。このPRたちをそれぞれの変更内容

今開発に関わっているプロダクトのCI/CD環境についてメモがてらやったことを書いていく。今回はデプロイパイプラインの土台部分の話。 前提: 構成 フロントエンドはNext.jsでVercelにホスティング。バックエンドはNest.jsでAWS上にECS FargateとAurora Serverless v2で動かしている。ORMはPrismaでIaCはTerraform。モノレポ構成で、フロントエンド、バックエンド、Terraformのインフラコードがすべてひとつのリポジトリに入れている。開発（dev）/本番（prod）で別AWSアカウントを使っていて、Terraformのtfbackendファイルで切り替える。 また、大事な前提としてはこれは新規でリリースするプロダクトなのでデプロイパイプライン構築時点では本番はおろか開発環境も暫定的なもの、というかVercelのプレビュー環境くらいし

最近注目を集めている Git 互換の新世代 VCS、Jujutsu。 2022年から公開されていましたが、しばらくは知る人ぞ知る存在のツールでした。それが 2025年中ごろから急に界隈で話題に上るようになりました。それは折しも Claude Code などのエージェント型 AI コーディングツールが登場し、人ではなく AI がほとんどのコードを書くフローが普及してきた時期に重なります。 本書では Jujutsu がなぜ AI 支援開発のシーンで評価されるのかを解説していきます。 ※この記事は 2026 年 4 月開催の技術書典 20 に合わせて刊行された『じゅじゅちゅ！ jj new で始める Jujutsu × AI ワークフロー』の中の「第 1 章 Jujutsu ってどんなツール？」の内容を再編成したものです。 https://oukayuka.booth.pm/items/8169

AIを使ったスライド作成は以前から可能でしたが、作った後に編集できないという課題がついて回りました。例えばNotebookLMでは、多彩なデザインのスライドをpptxファイルとして出力できるものの、各ページが1枚の画像として埋め込まれるため、文字や図表を後から修正するのが困難です。 その点、Claudeで作成したスライドはパーツごとに分かれたpptxファイルとしてダウンロードできるため、PowerPoint上でそのまま編集できるのが大きな強みです。さらに、専用のスキルを活用すれば、洗練されたデザインのスライドを安定して繰り返し生成できます。 本記事では、このパワポスライド作成用スキルの作り方と使い方を解説します。今回作成したスキルも公開しますので、ぜひご活用ください。 １．パワポスライド作成用スキルの作り方(1) 参考にするスライドの準備最初に、参考にするスライドやスライド作成のためのプロ

家庭内の紙はすべてNotebookLMへ！スキャナー×GAS×Googleドキュメントで、超効率なペーパーレスを実現する方法！ 学校でも家でも、僕たちの周りには常に「紙」が溢れています。 学校の教員として働いていると、配布物や提出物の山に囲まれるのは日常茶飯事ですが、家に帰ってもそれは変わりません。 保育園や小学校から届く大量のおたより、自治体の広報誌、家電の説明書……。 これらを「綺麗にファイリングする」のは、正直に言って限界があります。 僕もこれまで何度もペーパーレス化に挑戦してきましたが、スキャンしてPDFにするだけでは、結局「どこに何があるか分からない」というデジタルのゴミ屋敷を生むだけでした。 僕たちが本当に欲しかったのは、整理されたフォルダではなく、「あのおたより、提出期限いつだっけ？」と聞いた瞬間に答えを返してくれる「外部脳」ではないでしょうか。 さまざまな試行錯誤の末、よう

概要 まるで新入社員に業務マニュアルを渡す感覚で、Claude Codeに「このルールで動作して」「この作業は専用のツールや手順に任せて」といった指示を与えられます。プログラミング経験がなくても、用意された設定ファイルを適用するだけで、実務に耐える開発環境を簡単に整えられる便利なテンプレート集です。 このプロジェクトは、Anthropic社のCLIツール「Claude Code」を最大限活用するための設定ファイル集です。 プロジェクト構成 everything-claude-code/ ├── agents/ # 専門エージェント定義 ├── commands/ # スラッシュコマンド ├── contexts/ # コンテキスト切り替え設定 ├── examples/ # 設定ファイルのサンプル ├── hooks/ # イベントトリガー自動化 ├── mcp-configs/ # MC

Follow UsアカウントフォローでOtonamiをもっと身近に 最新情報をお届けするほか、 会員限定のイベントなどをご案内します。

【最新バージョンはこちらです】 Claude Codeの開発者である Boris Cherny氏 (@bcherny) が公開した「2026年の開発セットアップ」が、Claude Codeを使う全人類が読むべき内容でした 彼が実践しているのは、単なるツールの使いこなしではありません。 人間自身のCPUをマルチスレッド化するという、エンジニアリングの極致です。 そこで、この記事では彼が明かした驚異のワークフローを解剖し、我々が今すぐ取り入れるべき次世代の開発思想を深掘りします。 1. ターミナルとWebで「多重影分身」 まず度肝を抜かれるのが、同時に稼働させているClaudeの数です。 「AIの回答待ちにスマホを見る」。そんな無駄な時間は、彼の辞書にはありません。 彼は、常時10〜15体ものClaudeインスタンスを並列で従えています。 ここまでくると「一人の開発者」ではありません。AIエー

Tailwind CSSの騒動 Tailwindのビジネスモデル 問題の本質は収益化の導線が死んだこと これはTailwind固有の話なのか？ /llms.txt が突きつけるジレンマ OSSを使う側として じゃあどうするのか Tailwindの騒動は、前兆に過ぎないかもしれない Tailwind CSSの騒動 Xでも投稿したがTailwind CSSがなかなか大変なことになっている。 Tailwind大変なことになってるな。 公式ドキュメントをAIフレンドリーにするためのPRを作られたんだけど、そのスレに開発元のTailwind Labs Inc.のAdam氏が結構衝撃的な内容を投稿。…— Keisuke Nishitani (@Keisuke69) 2026年1月8日 Tailwind CSSとはオープンソースで提供されているこの数年でとても人気が出たCSSフレームワークだ。ここ数年で

はじめに 「顧客視点は“必要条件”であって“十分条件”ではない」 よくビジネスサイドから「エンジニアもビジネスを意識しろ」なんて言われることがあるだろう。エンジニアの間でも「ビジネスがわかるエンジニアにならなきゃ」という会話はよく耳にする。Xなんかでもよく目にする。 でも、そこで語られている「ビジネスを意識する」の中身が、どうも自分にはしっくりこないことが多い。今回は、エンジニアがビジネスを意識するとは結局どういうことなのか、自分なりの考えを整理して書いていく。いわゆる、ポエムだ。これ以降でエンジニアという言葉はITのエンジニアを指す。 ちなみに自分はどういう立ち位置の存在かというと、ずっとエンジニアをやってきて、ここ最近は本職としてビジネスサイドだけをやっている。ただし、今も個人の活動として少しだけエンジニアリングにも携わっている。どんな人なのかについてはXをフォローしてくれるといい。