ローカルAIを活用したら、大量のサブスクが解約できたぞ！ | ライフハッカー・ジャパン
日頃から、検索や要約といった用途でAIの契約をしている人も多いのでは？ これ、ローカルLLMさえあれば、より簡単に、より効率的に作業することができるんです。 ローカルAIにファイルを読み込ませる仕組みローカルLLMに「ファイルへのアクセス権を与える」のは、ハードルが高そうに聞こえるかもしれませんが、実は思っているよりも簡単です。 私はRAG（Retrieval-Augmented Generation：検索拡張生成）と呼ばれるアプローチを使用しました。 ドキュメント全体をAIのウィンドウにコピペするのは時間がかかり、トークンのコストもかさむためすぐに利用制限に達してしまいます。その代わりにRAGを用いることで、ファイルを小さな塊に分割して、手元のローカルデータベースに保存可能な「ベクトル埋め込み（AI向けのデータ形式）」に変換することが可能です。 AIに質問すると、システムはもっとも関連性
AnthropicがAI SREの限界を公式認定。「相関関係を因果関係と誤認し続ける」
Anthropicは2026年3月19日のQCon Londonで、ClaudeをSRE（サイト信頼性エンジニア）として活用する試みの限界を公式に報告しました。「相関関係を因果関係と誤認し続ける」という根本的な問題が残存しており、SREの完全代替には至らないと自社が認めた形です。AIにエラーログやアラートを読ませて原因を特定しようとしたことがある方には、直接関係する話です。 何を試みて、何が分かったか AnthropicはClaudeを使ってClaudeのインフラ障害を修復する、いわば「AIがAIを管理する」構成を試みていました。ログやメトリクスを読ませ、警告アラートの原因を特定させ、修復アクションを実行させるという流れです。 結果として明らかになった問題は、警告の表面パターンは認識できるが、障害の根本原因を特定できないという点でした。たとえば「メモリ使用量が急増した後にレスポンスタイムが
AIによる実装の品質が微妙で毎回自分で指摘しまくる必要があったので、確認前に自動で品質を上げさせるようにした - $shibayu36->blog;
Claude Codeに実装させた後、毎回自分でコードレビューして突っ込みを入れるのが大変だった。そこで、実装後に自動でセルフレビューと修正をする仕組みを作ったので紹介する。 課題: Claude Codeで出力されたコードの品質が自分の基準を満たさない Claude Codeで一気に実装ができるようになった反面、出力されたコードの品質が自分の基準を満たさないことが多かった。そのため、変更のたびに毎回ツッコミを入れていて、かなりの手間がかかっていた。プランモードで事前にちゃんと設計したとしても、コードレベルでは満足いかないことが多かった。 じゃあサブエージェントやCodex CLIで先にレビューして直し切ってもらってから確認すれば良いのでは？と思ってやってみた。しかし、AIのレビュー指摘には的外れなものや過剰なものも混じるため、全部対応させるとかえってコードが散らかってしまうこともあった。
CLAUDE.mdを設計するとClaude Codeの生産性が別物になる — 実際の設定と運用ワークフローを公開 - Qiita
はじめに Claude Codeを使い始めた直後は感動します。自然言語でコードが書ける、テストも回してくれる、リファクタリングまでやってくれる。ところが1ヶ月ほど経つと、壁にぶつかります。 「前にも同じ指示を出したのに、また違うスタイルで書いてくる」 「プロジェクトのルールを毎回説明するのが面倒」 「サブエージェントを使いたいけど、どう設計すればいいかわからない」 この壁を越えるカギが CLAUDE.md の設計です。 筆者は本業・副業・個人開発を並行して進めており、Claude Codeを日常業務のパートナーとして使っています。最初は雑にCLAUDE.mdを書いていましたが、構造を設計し直してから、指示のやり直しが激減しました。この記事では、実際に運用しているCLAUDE.mdの設計と、それを軸にしたワークフローを公開します。
Coding Agent時代の開発ワークフローについてのまとめ
こんにちは！逆瀬川ちゃん (@gyakuse) です！ 今日はCoding Agent時代の開発ワークフローについて、みんながやっているものからわたしがやっている手法までまとめて紹介していきたいと思います。 前回の記事 Claude Code / Codex ユーザーのための誰でもわかるHarness Engineeringベストプラクティス では、LinterやHooks、テスト戦略といった決定論的ツールでCoding Agentの出力を矯正するHarness Engineeringに特化しました。 今回はその上位にある問い、つまりハーネスは分かったけど全体としてどう開発を進めればいいのか、に答えます。プロジェクトの進め方、Agentとのコーディングテクニック、それを支えるインフラの3つの視点から2026年3月時点の状況を整理し、最後にわたし自身のワークフローも紹介します。 Agenti
南場智子「ますます“速さ”が命題に」DeNA AI Day2026全文書き起こし - エンジニアtype | 転職type
NEW! 2026.03.08 ITニュース DeNA生成AIAI 「開発エンジニアの人生が一変した1年」だった――。 2025年に「AIオールイン」を宣言したDeNA。あれから1年、会長の南場智子さんは劇的な変化をそう切り出した。 コーディングに手を動かすことが激減し、AIが自らタスクを請け負うAIエージェントが民主化したこの1年。最前線で南場さんが痛感したのは、生産性向上という甘い果実だけではない。 「無慈悲なLLM」 「中途半端な専門性は一撃で淘汰される」 「スピード感のないプロダクトに、成長も参加資格もない」 突きつけられたのは、昨日までの常識を無効化するシビアな現実だ。 しかし、南場さんは同時にこうも断言する。 「諦めるのは時期尚早。日本はまだまだ勝てる」 その真意と、南場さんの描く未来予測とは？ 2026年3月6日に行われたばかりの最新プレゼンを、熱量そのままにノーカットでお届
ついにローカルLLMで安心して仕事が出来る！― Qwen3.5-27B 採用レポート (2026/02/27)
ついにローカルLLMで安心して仕事が出来る！― Qwen3.5-27B 採用レポート (2026/02/27) TL;DR ・RTX 3090（VRAM 24GB）＋5bit量子化で Qwen3.5-27B (Reasoning) を実用速度でローカル動作させた話。 ・Artificial Analysis の Intelligence Index 上では、 Qwen3.5-27B (42) ＞ o3-pro (41) ＞ Qwen3.5-35B-A3B (37) という並びになっている。 ・実際のコーディング体験でも、長めのタスクのやり切り／コードの一貫性／プロンプト耐性の3点で 27B が 35B-A3B を上回ると感じたため、「常用エンジン」は 27B を採用。 ・TypeScript + Canvas で Pong / Breakout / Tetris の3本をワンショット生成し
「全エンジニアが Claude Code を 100% 活用する」を目指してダッシュボードを作った
はじめに 「全エンジニアが Claude Code を 100% 活用する」 これは、ダイニーの今期の目標のひとつです。 正直、最初に思ったのは「何をもって 100% なんだ？」です。 手がかりを探るために、まずチーム全員にアンケートを取りました。 結果はバラバラで、「かなり活用できている」という人もいれば、「スキルやサブエージェントはほとんど使えていない」という人もいます。 中でも多かったのが、「他の人がどう活用しているのか分からない」という声でした。 実際、有志がスキルやサブエージェントを作っても、その存在自体を知らないメンバーがいます。知っていても中身が分からないから使えない。結局、作った本人しか使わないまま埋もれていく。そんな状態です。 これでは「活用度」以前の問題。 そもそも何が使えるのか、誰がどう使っているのかが見えなければ、活用度を定義できません。 そこで作ったのが、エンジニ
オタクちょろっ。SteamのAIゲーム『サーガ&シーカー』が萌え豚カプ厨にとって発狂するほど面白い件。｜海燕（エンタメ系ライター／ITmedia「ねとらぼ」連載中）
最初から幾人かのキャラクターがインストールされていて、なんかひろゆきとかも入っているんだけれど、だれがひろゆきなんか（失礼）使うか。 ということで、とりあえず海燕（プレイヤー）、間桐桜（『Fate/stay night』）、美樹さやか（『魔法少女まどか☆マギカ』）、ダグラス・カイエン（『ファイブスター物語』）でパーティーを組んでみました。 この四人で「〇〇しないと出られない部屋」へ入ってみたり。いやー、これ、めちゃくちゃ面白い。笑える。 まず、ちょこちょこ性格設定とか口調設定をいじって桜とかさやからしいキャラクターを作成してみたんだけれど、何だろう、アイコンを設定してそれっぽいしゃべりかたさせるだけでそこそこ桜っぽく見えるし、さやかっぽく思える。 海燕 さんざん悩んだあげく、桜に対して質問してみる。「きみ、ほんとはそんな善い子じゃないよね？ ほんとうは心が壊れているんだろ？」 間桐桜 「…
SaaSは死なない、ただし「人間がUIを触る前提の設計」は終わる──AIエージェント時代のSaaS再設計論 - Qiita
はじめに 2026年に入って「SaaSは死んだ」という言説を目にする機会が増えました。AIエージェントが業務を代替するようになれば、従来のSaaS製品は不要になる──そういう論調です。 しかし、実際にAIエージェントを開発・運用しているエンジニアの立場で見ると、話はそう単純ではありません。 SaaSは消滅しません。ただし、「人間がUIを操作する前提のSaaS設計」は終わりつつあります。 この記事では、煽りや市場予測ではなく、AIエージェントを組み込む側のエンジニアが直面している技術的な課題と、SaaS側に求められる設計変更を整理します。 この記事の対象読者 AIエージェントの開発・運用に携わっているエンジニア SaaSのAPI設計やアーキテクチャに関わるエンジニア エージェント統合を前提としたシステム設計に興味がある方 この記事で得られること エージェント時代にSaaS設計の何が変わるのか
Antigravityを「経営コックピット」にする：Googleドライブ×GitHub×RAGエージェントで実現する一人CTO戦略
Antigravityを「経営コックピット」にする：Googleドライブ×GitHub×RAGエージェントで実現する一人CTO戦略 3行でまとめ 個人開発者の脳内は「実装」「営業」「発信」で分断されがちで、コンテキストスイッチのコストが高い VS CodeベースのAIエディタ(Antigravity)に全リポジトリとGoogleドライブを集約し、エージェントに「横串」を通させる 「過去の自分（職務経歴書）」をAIに参照させることで、文脈の通った戦略立案が可能になる はじめに：個人開発者は「一人CTO」であり「一人PM」である 個人開発者や一人法人の代表として活動してると、 「脳の切り替え」 に凄まじいエネルギーを使いませんか？ 👨💻 エンジニアモード : バグ修正、機能実装、テスト 📈 マーケターモード : LPの改善、コピーライティング 📢 広報モード : ZennやXでの発信
Claude CodeにRemotionスキル入れたら、仕事でも使えるかもな動画制作が“別ゲー”になった｜AIこぐま
Claude CodeにRemotionスキル入れたら、仕事でも使えるかもな動画制作が“別ゲー”になった はじめにこんにちは！みなさま、動画生成してますかー！？ Remotionという、Claude CodeやCodexなどで使える動画のエージェントスキルがあるのですが、これを使ったら仕事でも使えそうな映像が作成できたので、その紹介記事です。 Remotionは、Reactのコンポーネントで動画を作れるフレームワークです。通常の動画編集ソフトとは違い、コードでアニメーションを制御できるため、プログラマーにとっては非常に強力なツールです。 ただし、Remotion特有のAPIを正しく使いこなすには、それなりの学習コストがかかります。 そんなRemotionが、Claude Codeのスキルとして公式に提供されるようになりました。これにより、自然言語だけで3Dを含む映像の作成が驚くほど簡単にな
一番の脆弱性は"人間のコードレビュー"だった
「LGTM 🚀」 このたった4文字、何回書いてきただろう。 PRが来て、差分を見て、ロジックを追って、「まあ問題なさそうだな」でApprove。正直、金曜の夕方に来た30ファイル変更のPRに対して、全行を真剣に読んだかと聞かれたら——答えに詰まる。 たぶん、あなたもそうだと思う。 はじめに 認証・認可、入力バリデーション、そのあたりを「ちゃんとやってるつもり」で何年もやってきた。 でも最近、自律型AIエージェントにセキュリティテストを任せてみたら、僕が一番信頼していた「人間のコードレビュー」が、実は一番のザルだったと気づいた。 ツールを入れて満足する話じゃない。もっと手前の話だった。 AIハッカーの時代が来た、らしい 2025年あたりから、AIを使った脆弱性スキャナーが一気に増えた。 中でも話題になったのが Shannon。GitHubでトレンド入りした自律型AI脆弱性スキャナーで、LL
完璧な仕様は、もう設計できない - Nothing ventured, nothing gained.
ここ数年、AIがプロダクトを大きく変えると感じ、従来と何が違うのかが気になってきた。投資家としても海外を含むスタートアップやプロダクトを見る機会が増える中で、AIを前提に設計されたプロダクトには、従来とは明らかに異なる成功パターンがあるように感じている。 それは、AIが中心となるプロダクトの設計には、「完璧な仕様」を追い求める従来の手法とは異なる、新しい姿勢が求められているということではないか。プロダクトを完成させるのではなく、変化し続ける前提で設計するという姿勢だ。 たとえば、AIコードエディタとして登場したCursorは、VS Codeという巨大な既存プロダクトが存在する市場において、またたく間に支持を集めた。VS CodeにもGitHub CopilotをはじめとするAIサービスのアドオンを追加することはでき、AI機能そのものは利用可能だったにもかかわらずである。 Cursor以前の
続・AIのためのオンボーディングドキュメントを整備する (2026年1月版) - inSmartBank
スマートバンク新春エンジニア駅伝2026も第五区に差し掛かりました*1。 昨日の id:minisera によるクレジットカード番号の混入を防ぐ技術 - inSmartBank はまさにカード決済に携われるエンジニアリングならではの記事でした。打って変わって本記事はSoftware Engineer / Engineering Managerの id:ohbarye が旬と思しきAIトピックをお届けします。 去る2025年3月、弊社が公開した『AIのためのオンボーディングドキュメントを整備する』ではAIコーディングツール活用時に期待した通りの成果物にならないという課題と、その解決策としての「AIのためのオンボーディング整備」について紹介しました。 あれから約10ヶ月が経過する中で起きたツールや周辺状況の変化に合わせ、以前の記事で紹介したAI向けオンボーディングドキュメントを再整理しました。
「分かりやすい文章」を言語化してみた - NRIネットコムBlog
生成AIの進化によって、誰でも文章や説明資料を簡単に作れる時代になりました。 しかし、設計書やプレゼン資料など、読み手に何かを伝えるアウトプットでは、構成や文脈への配慮が欠かせません。 私自身、エンジニアとして日々、文字によるアウトプットを行う中で、「伝わる文章」を意識しています。このブログでは、日本語的な文法の話というよりかは、ドキュメントとしての文章設計のポイントを実体験を交えて考察していきます。 また、各セクションでは「こうすると伝わりづらくなる」というアンチパターンも紹介しています。実際の現場でありがちな落とし穴にも触れながら、伝わる文章の設計ポイントを考えていきたいと思います。 生成AIの時代に求められる力 分かりやすい文章とは何か? 分かりやすい文章作成の具体的なアプローチ 1. ペルソナ設定 2. 構造化 1.メンタルモデルの構築 2.親子関係の意識 3.ストーリー構成のチェ
フルVibe Codingでも仕事が進むようになってきた2025年
（フルVibe Codingできたとは言ってない） ご無沙汰しております。 今年の後半から大学の講師(情報学部)もするようになって、すっかり時間がなくなっていたkazuphです。 基本的にすべての仕事が副業みたいになった昨今、細切れの中でなんとしても進捗を出す必要があり模索してきました。私は15年程度エンジニアをやっていますが、Claudeの性能が上がってからはコードを読むのをほぼやめています（自分が得意で好きな部分だけ見ますが）。 特に今年傾倒したのがPlanモードや仕様駆動開発（SDD）です。 Claude CodeのAgentに対応したSDDは神がかっており、こっちは要件を言うだけでどんどん別のagentがフェーズごとに立ち上がってアウトプットを出してくれます。Agentの文言を改変して、作成した仕様やtasks等を実行する前に自動でCodexにレビューさせたりすると更に威力が高まり
APIをそのままMCPサーバーにするな
散々言われていることだと思いますが、何度でも言いたいことなので、改めて記事にすることにしました。 APIをそのままMCPサーバーにするのは止めてください 何故ダメか 何故ダメかの説明として、よく「APIとMCPはレイヤーが違うから〜」とか説明されているのを見ますが、個人的にはそんなことはどうでも良くて、普通に実害があるからダメです。主に以下の2点が問題です。 AIのコストが高くなる AIの応答精度が悪くなる 特に1はめちゃくちゃ困ります。 逆に言うと、これらの問題が発生しないように考慮されていれば、私的にはAPIをMCPサーバーにしてもOKです。 では何故、深く考えずにAPIをそのままMCPサーバーにするとAIのコストが高くなるのか、もう少し深堀りして見ましょう。 AIエージェントの処理 問題を把握する前に、いわゆるAIエージェントがMCPサーバーのツールを使う時の処理を理解しておきましょ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仕様漏れ実装漏れをなくすトレーサビリティAI基盤のご紹介
AI時代のアジャイルチームを目指して ー スクラムというコンフォートゾーンからの脱却 ー / Toward Agile Teams in the Age of AI
