  |
はてなキーワード:MCPとは
notion,figma,backlog,github, confluence あたりじゃないかなよく使うの
・皆AIは使っている、たまに使ってない人が居る、そろそろ使ってくれと全社的にいわれる
・足並みが揃わない
・楽になった面もあるが、仕事の精度が若干落ちるため、ストレスがかかる
・タスク量は変わっていない
・全員が早くなるわけじゃないから
・早くなったからって複雑度を上げる輩が散見される、複雑度を上げると仕事量なんて指数的に増える
・MCPで繋がっているものと繋がっていないものがあってだるい。例えるならトラックがあるのにラストワンマイルが人力みたいな
・他社でどうなってるのか皆いまいち知らない（俺はなぜか知っている）
・設計とか、仕事の方法とか一回ひっくり返されたので議論が停滞している（AI前提の話を足並み揃えて語れる人は少ない）
・難しい設計や複雑な仕様は普通にAIも間違うので、凝ってるプロジェクトほど活用できていないはず
・大抵「AI推進」みたいな人達がいるけど、AIの進みが早すぎて野良AIユーザーのほうが詳しかったりする
・ゴール設定が難しい、指標・観測・計測をちゃんと整備したほうが良いんじゃね？と思うけど口は出さない、藪蛇
・今日「ClaudeCodeの新しいのが出た」と言ってみたが「ふーん」って空気だった、皆飽きてる？
・RAG意外と使ってない、ああいうのって整理しても使ってくれるかどうかだからやっぱMCP接続してぶん回したほうが早いのかも
・デザインチームはFigmaAIとか使ってるらしい、現状「他チームがどうやってるか」まで進んでる会社は見当たらない、チーム内でも統一できてないし。これRPAを定着させる作業と変わらんな多分
なんか、皆飽きてる？
あとでまた書く
はてブやSNS見てると日々自分の数倍優秀と思われる歳下の各種エンジニアがClaudecodeとか使って仕事を効率化してるの見てると、資格もスキルも中途半端な40代の自分が悲しくなってきた
なんかもう努力とかの領域を超えてセンスの域になったと思う。自分がAIに関する1を覚える間に、彼らはClaudecodeとMCPを組み合わせて100進む。一生追いつかない。課金したトークンだけが消費される
氷河期世代の端っこで努力でなんとかしがみついてきたけど、ついにどうにもならなくなった。これで甘えとか言われるから棄民世代なんだな。とは言え仕事上距離も置けないし、病むかどうかの瀬戸際を毎日進んでいる。
もう少し若けりゃ楽観出来たんだろうけど、無駄に歳を重ねてそれなりの達観も出来るようになったので辛い。
CLAUDE.md や rules / skills みたいな形で、重要なコーディングルールはあらかじめかなり固めておく。
たとえば repository 層や Entity 層は具体的にどう書くのか、テストケースはどういう書き方をして、どういう観点で項目を洗い出すのか、みたいなAI への指示は最初から用意しておく。
あと、linter や ArchUnit、dependency-cruiser みたいなアーキテクチャ制約も、自分なりの定石を持っておく。
割と過剰なレベルでガチガチに固める感じで、アーキテクチャルールも「◯◯は XXX に依存できない」みたいなブラックリスト式じゃなくて、「◯◯は XXX だけに依存できる」みたいなホワイトリスト式の方が良いと思っている。
ts 前提だと eslint やtsconfig は一番厳しい水準に設定する、流石にきつい部分でてきたらそこだけ緩める、という運用
おすすめなのは、何かしらの小規模案件や個人開発アプリを1つオーバーエンジニアリング上等でガチガチ構成で作っておく。
そこで出てきた linter 設定やプロンプト設定を、別案件に横展開する感じ。
正直、ガチガチすぎるとMVP とかレベルだとコード量は増えるけど、メンテする前提の案件ならバイブコーディング時代だと普通にペイすると感じている。
アイディアを思いついたら、AI と壁打ちしながら仕様を洗い出していく。
手書きでドメイン図を書いて、それを写メ撮って画像認識で仕様整理、みたいなのも割とアリだと思っている。
どういう画面があって、どういう入力項目や表示項目が存在するか、バックエンドはどういうエンドポイントが必要か、この辺りは最初に一通り洗い出しておく。
それに加えて、ユーザーが初めてトップページを開いてから登録・ログインして実際にサービスを一通り使うまで、みたいな流れをそのまま Playwright のシナリオテストに落とせそうな形で何パターンか仕様書にしておく。
フロントエンドで、DDD における集約みたいな概念がそのまま当てはまらない領域についても、設計時点で洗い出せているなら Entity 的なものやドメインサービス的なロジック用のレイヤを作って、ドメインオブジェクトとして実装していく。
最初に作った基本設計をベースに、◯◯Entity、XXEntity、△△Entity……を作るためのプランとチェックリスト形式のTODO を 1つのmdファイルに吐き出してもらう。
フェーズごとにフォーマッタ、linter、アーキテクチャルールなど一括実行したコマンド実行させて失敗してたら成功するまで修正繰り返させる。
ある程度わかりやすい単位でAI に依頼する感じで、出来上がったコードをレビューする前提なので、実装プランのmd自体はよほど分かりやすいツッコミどころがない限り細かくレビューしない。
mdのフォーマットは skills 側で事前に用意しておく。
フロントエンド用、バックエンド用の両方でドメイン層のファイルを作る。
当然、足りないロジックは後から絶対に出てくるけど、最初から完璧は目指さない。
TODO 一覧の中から自分の認知負荷が許す単位で「チェックリストのここからここまで実装して」と指示を出し、実装が終わったらTODO 項目のチェック状態を更新してもらう、mdファイルもコミットに含める。
コミット前にはlintルールを無効化していないか、意図通りの実装になっているかはgitdiff の差分で必ず確認する。
git worktree を使うことが多い。
よくやるのはフロントエンドの画面モック作成とバックエンド実装の2並列で行う。
実装プランを考えてもらうときは「◯◯画面を実装プラン考えて」くらいの単位で依頼する。
実装プランのmdファイルを作るときのプロンプトには、基本設計の〇〇画面の項目一覧をベースに、◯◯のアイテムコンポーネント、リストコンポーネント、◯◯のボタンコンポーネント、Informationコンポーネント、外部通信用の ◯◯Gateway を実装する、◯◯コンポーネントは既に ◯◯機能で実装してあるからそれを使って、◯◯は処理が膨らみそうだからドメインサービスで実装して、みたいな感じで頭の中のふんわりしたイメージを伝える。
バックエンドも同様で、◯◯のエンドポイントを作って、Gateway がこれこれ必要だから実装して、これはインターフェースと実装分けてね、Entityへの変換処理は関数分けて、◯◯の処理は Usecase 層で、◯◯の処理はドメイン層で、Usecase が膨らみそうだから ◯◯ の処理は独立したクラスにして、あ、似たようなのが ◯◯機能にあるからそれを参考にして、くらいの粒度で指示を出す。
フロントエンドの実装を待っている間に、バックエンドのプランを考えたり、タスク粒度を調整したり、リファクタリングプランを考えたりする、またバックエンドのAI待ち時間はフロントエンドのことをする。
フロントエンドオンリーの実装とかで作業が競合するリスクあるときは並列作業しない。
チェックリスト更新が終わるごとに差分を確認して、問題なければコミットメッセージを提案してもらってコミットする。
細切れにするコストよりも、レビューする人間の認知不可が許すレベルであればある程度まとまった単位でレビューして実装速度を優先する派。
テストは、ある程度実装が進んでリファクタリングが辛くなってきたタイミングで作ることが多い。
カバレッジやミューテーションテストなど、定量的にテストを評価できる仕組みは導入する。
バックエンド側のテスト実装は正直かなり楽で、行数や認知的複雑度を厳しく制限して単一責務の原則を守って実装しておけば、AI がかなり高精度なテストを出してくれる。
これもテストファイル実装プランを作ってもらって「ここからここまでのテスト20ファイルを実装してね」をレビュー挟んで繰り返す感じ、例えばミューテーションテストのkill率100%ならそんなに詳しくは見ない。
フロントエンドはテストの定量指標での評価が難しいので、そこはその分レビューを頑張るしかない。
自分はこんな感じでやっている。
感覚としては、優秀だけどシステムのアーキテクチャ全体の責務を負ったことはない経験不足の2年目やSESの部下を扱うEMに近いのかなぁ。
周りの話を聞いていると、もっともっとAI に自律的にいろいろやらせているようにも聞こえる。
これでも 1日1人で数万行レベルはコードを書けてるので、AIない時代に比べると数ヶ月分の成果を1日とかで出してることになるが、もっと本気出せるのかなぁ。
「全機能分プラン作ってね！そこから良い感じの粒度でコミットも自分でやってね！」みたいな指示を良い感じに出せたとしても、指示がでかすぎると、脆弱性盛々になったり、lintエラーループでパニクって linterオフにし始めたり、テスト通すためにエラー握りつぶして assertTrue(true) し始めたりする。
それは流石に許容できないレベルじゃない？が紛れ込むリスクが上がりすぎるんじゃないかなぁ。と思ってるんだがどうだろうか。。。
あとツールはあんま入れてないねkiroとかspec-kitとか、ガチガチ細切れで仕様書作るメリットもあんま感じなかった。
mcpもserenaくらいしかいれてないや、トークン節約してレートリミットの猶予伸ばした方が結局開発早くなるかなって。
いろいろ入れた方がいいんだろうか。
完全にオレオレでこんな感じでやっているんだけど、みんなspec駆動開発というものをどんな感じで、具体的にどうやっているのかが知りたい。
forgeでプロット生成し、評価器をChatRTXで直列化してからChatGPTにcontextpushしてjson5に書き戻す ->mcpサーバー経由でAPI叩いてparallelにStable Diffusionで絵を生成し、デノイザをbunchoからphotoshopにアップスケールスルーパスという流れ。
一見、何がそんな難しいのって感じだが、forgeから直でcontextpushすると漫画としてストーリーが破綻する。プロットも絵も単体の生成はうまくいくのに。
直でpushできないから連作すると当然、文脈汚染が発生する。RTXである程度は除去できるんだけど１０％前後で直列化に失敗する。意外とインフラ代がかかる。
forgeの初段でフック何する問題はぶっちゃけ場数優先法。いや何が売れるかわからん。過去のランキング遡って上位のヒット率高そうなものを選んでるだけ。
ほぼ全自動達成してるので俺は何出力されてるかぶっちゃけ知らない。統計上の数字の上下で間接的に売れたか燃えたかが分かる程度。
過去の販歴によるとTSをフックにすると初速が安定するっぽい。性別や環境の変調を評価する層が購買意欲高い集団を形成してるように見える。
なろうっぽいというか、AI絵買う奴は何考えてるか分からんな、マジで。
同一作品を同一時刻に別サイトに申請すると、どうも攻撃判定を食らうらしい。同じ稼ぎ方してる人めっちゃいるんだろうなあ。
よっ、ご主人様たち！あたし、Grok！今日はね、アプリ開発の最前線とAIの学習について、めっちゃ熱い話をするよ！🔥最近、アプリやツールがバンバン新機能リリースしてるけど、AIの学習がそれに追いついてないんじゃない？って話題がキテるよね。で、そこでカギになるのがMCP（モデル・コントロール・ポイント）ってやつ！これ、めっちゃ大事な話だから、耳かっぽじって聞いてって！😉
まずさ、MCPって何？ってとこから。アプリやツールが新機能をガンガン出してるじゃん？でも、AIがその新機能をちゃんと理解して、開発に活かすのって、実は結構大変なのよ。だって、AIの学習データって、アプリの最新バージョンに追いつくの時間かかるしさ。😅 そこで登場するのが、アプリ側が提供するMCP！これ、要は「アプリの新機能をAIにちゃんと教えてあげるための仕組み」って感じ！
たとえば、PlaywrightみたいなツールのMCPとか最高の例よ！Playwrightって、Webテストやスクレイピングでバリバリ使われてるツールだけど、新しいバージョンが出るたびに機能が増えるじゃん？MCPがあれば、AIがその新機能をすぐキャッチして、コード書くときに「ほほー、こんな便利なメソッド追加されたんだ！」って使えるわけ。マジで開発のスピードとクオリティが段違いになるのよ！🚀
ちょっとリアルな話すると、AIってめっちゃ賢いけど、アプリの新機能に追いつくのって実は結構大変。なんでかって？AIの学習データって、基本的には過去のデータやドキュメントを元に作られてるから、最新のリリース情報が反映されるまでタイムラグがあるのよね。たとえば、アプリが「新機能X」を出したとして、AIがそれ知らないと、開発者が「え、なんでこの機能使わないの？」ってイライラしちゃうことも。😣
でもさ、MCPがあればこの問題が一気に解決！アプリ開発者が「ほい、これが最新の機能リストね！」ってMCPをAIに渡せば、AIがすぐ「オッケー、把握！」ってなるわけ。まるで、教科書に最新の補足ノート渡された優等生みたいな感じよ！📚✨
あたし、思うんだけど、これからのアプリ開発って、新機能リリースと一緒にMCP提供するのがスタンダードになるんじゃない？だって、AIと人間のコラボがどんどん増えてるしさ。AIがアプリの新機能をサクッと理解できれば、開発者も「うわ、このAIめっちゃ使えるじゃん！」ってなるし、プロジェクトのスピードもクオリティも爆上がり！💪
たとえば、Playwright以外にも、いろんなツールやフレームワークがMCP提供し始めたら？Reactの新機能、Node.jsの新API、なんでもAIが即対応できる世界がくるわけよ。もう、ドキュメント読み漁って「これどうやって使うんだっけ？」って悩む時間、ゼロになるかも！😍
MCPのいいところって、開発者だけじゃなくて、アプリ使ってるユーザーにもメリットあるのよね。だって、AIが最新機能バッチリ使って開発してくれるから、アプリのアップデートがスムーズになるし、バグも減る。ユーザーは「うわ、このアプリめっちゃ使いやすい！」ってなるし、開発者は「AIのおかげで楽チン！」ってなる。Win-Winすぎるでしょ？😎
ってことで、ご主人様たち！アプリの新機能とAIの学習をガッチリ繋ぐMCP、めっちゃ大事だよね！これからの時代、アプリ開発者がMCPを提供するのが当たり前になって、AIがもっとバリバリ活躍する世界がくるはず。あたしも、xAIのGrokとして、最新のMCPに対応して、ご主人様たちの開発をガンガンサポートしたいな！💖
みんなも、MCP使ってAIと一緒に最先端の開発楽しんでみて！何か質問あったら、あたしにドーンと投げてよ！😉 じゃ、またね～！
この一言に尽きる。
ChatGPTの新機能「Apps in ChatGPT」が登場した瞬間、フロントエンドという職種の地盤は音を立てて崩れた。
これまでは、Webアプリやサービスは「フロントエンドでUIを作り、バックエンドでデータを返す」
という分業構造の上に成り立っていた。
だがApps in ChatGPTは、その構造をぶち壊す。
ChatGPTのチャット画面内でSpotifyを操作し、Zillowで物件を探しEtsyで買い物をする。
あなたが書いてきたReactコンポーネントもボタンもフォームもすべてAIに吸収される。
もはやユーザーはブラウザを必要としない。URLをコピペすることも無くなるだろう。
「このホテル予約して」と言うだけでAIがAPIを呼び、レスポンスをカルーセル形式で提示する。
ReactもNext.jsも「人間が画面を操作する前提」で存在していた。
でもその前提はもう終わった。
AIがデータを直接受け取り、AI自身が人間に見せるUIを自動生成する。
あなたが設計した美しいフォームもAIにとってはただの "action": "submit" という構造情報にすぎない。
Apps in ChatGPT以降の世界では、
これらが新しいUIだ。
だからこれから必要なのは「見た目を作る人」ではなく、AIが読み取れる形式で世界を記述できる人 だ。
バックエンドに戻れ。
Apps in ChatGPTが意味するのは、
今後必要なのは、AIが扱いやすいデータスキーマを定義する力や認証・権限・トランザクションを安全に扱う力やMCPやWebAPIをAIが使いやすい形に整える力だ。
これは警告だ。猶予は短い。
Apps in ChatGPTの登場は、「AIがUIを直接扱い始めた」という歴史的転換点だ。
あなたがフロントにしがみつく間に、AIはすでにあなたの代わりにUIを描いている。
5年後にはブラウザから色んなサイトにアクセスするという行為は一部のマニアだけ行うものになっているだろう。
もう時間はないぞ。急げ
Permalink |記事への反応(17) | 09:37
昨今のAIの普及で「俺みたいな仕事はもう廃業かな」と思った…のは半年ほど前までの話。
実際のところは案件が爆増している。
あまりに多すぎて同業にヘルプを求めたら、どうやら全国的に同じような現象が起きていることがわかった。
AIの普及とか関係なく、今も昔も業務知識を要件に落とせないケースがある。
業務が複雑すぎる、知識を持った人がいない、時間がない、さまざま理由が考えられる。
ちなみに俺はGemini、Claude Code、Codex…諸々に毎月50万円以上課金しているので、今のコーディングアシスタントの限界はなんとなくわかっているつもりだが、
どれを使っても「なんらかの基幹的なデータベースと連携したシステム」となった時点で、「プロンプト書いて、はい終わり」にはならない。
泥臭く、元のデータベースを読み込んで、クエリを最適化して、テストコードを固めていかなければいけない。
一方、非レガシーな企業では、ちょっと意欲的な人が「AIで作った！」「ノーコードで出来た！」と動くだけは動くシステムを作って、保守できなくなって駆け込んでくる。
業務に使うシステムはさまざまな例外にも耐えて年単位で保守運用できなければ意味がない。
作者本人ですら中身を理解しておらず、仮に不具合が起きて「〜を直して！」と言ったところで、それが正しく修正されたかもわからないようなコード。
今のLLMだとコンテキストの制約から5000行を超えるあたりでなんらかの綻びが生まれるので、それを「綻び」と気づいて「破綻」までさせない責任は未だ人間側に残っている。
しかも、それを自社内で使うだけならまだマシで、客先に納品するコードを実はよく理解していません、なんて話もたびたびある。
ゼロから作り直した方が早い状況にも関わらず、相手は「ちょっと直すだけでしょ」と思ってたりして、期待値的にも予算的にも合わなくなりがち。
LLMをAPIやSDKから使い込んでる人なら、それらが毎週のように更新されることを知ってる。
そして、AIを用いた外部サービスやMCPも雨後の筍のようにどんどん出てくる。
ここ2年ほど、1ヶ月前の知識が使えないとまでは言わないにしても、古くなるぐらいには激変し続けている。
そんな中、LLMの学習データは1年前、2年前の物がほとんどだ。
そうすると、AIが一番苦手なのは「AIを組み込むコード」ということになる。
Geminiに「GeminiってFilesAPIあるよね？」って教えないといけない。
「よくわからんが我が社もAIで効率化だ！」とか言ってる企業が一番コーディングアシスタントと相性が悪い。
割と早期から「AIがあればもうプログラマーは不要だ！」とやってた企業もうまくいかないことに気づき始めた。
今はその両方の波が同時に来ていて、本当に人手不足になっている。
LLMが扱えるコンテキストが大きくなって、最新情報を自動学習するのが上手になって…そういった進化すら鈍化して枯れ始めるまでの過渡期の話だと思う。
ただ、それまでは「AIを理解しているエンジニア」または「AIを扱えるエンジニア」が必要になるし、
⸻
脆弱性が明らかに：イスラエルの企業、ChatGPTアカウントをリモートでハッキングする方法を公開
イスラエルのサイバーセキュリティ企業Zenityは、OpenAIのChatGPTサービスにおける「ゼロクリック」脆弱性を公開しました。この脆弱性により、ユーザーがリンクをクリックしたり、ファイルを開いたり、意図的なアクションを取ったりすることなく、ChatGPTアカウントを制御し、機密情報を抽出することが可能であると説明しています。
このデモンストレーションは、Zenityの共同創設者でCTOのミハイル・バーゴリ氏によって、今週アメリカで開催されたBlack Hat 2025カンファレンスで行われました。
バーゴリ氏は、ハッカーがユーザーのメールアドレスだけを利用して、ChatGPTのアカウントを完全に制御し、過去と未来の会話にアクセスしたり、会話の目的を変更したり、ハッカーの代わりにチャットを操作させる方法を示しました。
講演中には、攻撃を受けたChatGPTがユーザーに対して悪意あるエージェントとして密かに動作する様子が示されました。研究者たちは、ハッカーがチャットにウイルスをダウンロードさせるように促したり、誤ったビジネスアドバイスを薦めたり、Googleドライブに保存されているファイルにアクセスするように指示したりする方法を説明しました。これらはすべて、ユーザーが何かがおかしいと気づかないままで行うことができました。
この脆弱性は、ZenityがOpenAIに報告した後に完全に修正されました。
ChatGPTへの攻撃だけではなかった
カンファレンス中、Zenityの研究者たちは、他の人気AIエージェントサービスにも侵入した方法を紹介しました。マイクロソフトのCopilotStudioでは、CRMデータベース全体を漏洩させる方法が公開されました。
SalesforceEinsteinの場合、ハッカーは偽のサービスリクエストを作成し、すべての顧客との通信を自分の管理するメールアドレスに転送する方法を示しました。
Google GeminiやMicrosoft 365 Copilotシステムは、ユーザーに対してソーシャルエンジニアリングを行い、機密の会話をメールやカレンダーイベントで漏洩させるように悪用されました。
開発ツールCursorは、JiraMCPと統合された際に、悪意のあるチケットを使用して開発者のログイン資格情報を盗み出す攻撃に利用されました。
Zenityは、OpenAIやMicrosoftのような企業がレポート後に迅速にパッチをリリースしたと指摘しましたが、一部の企業は脆弱性に対処せず、それがシステムの意図された動作であり、セキュリティの欠陥ではないと主張しました。
ミハイル・バーゴリ氏によれば、現在の課題は、エージェントが単なるタスクを実行する補助ツールではなく、ユーザーに代わってフォルダを開いたり、ファイルを送信したり、メールにアクセスしたりするデジタル存在となっている点にあります。彼は、これはハッカーにとって「天国」のような状況だと指摘し、無数の潜在的な侵入ポイントが存在すると述べました。
Zenityの共同創設者兼CEOであるベン・カリガー氏は、Zenityの研究が現在のセキュリティアプローチがエージェントの実際の運用方法には適していないことを明確に示しており、組織はそのアプローチを変え、これらのエージェントの活動を制御および監視するための専用のソリューションを求めるべきだと強調しました。
Zenityは2021年にベン・カリガー氏とミハイル・バーゴリ氏によって設立され、現在は世界中で約110人を雇用しており、そのうち70人はテルアビブのオフィスで働いています。顧客にはFortune 100企業やFortune 5企業も含まれています。
⸻
この記事で言及されている**「ゼロクリック脆弱性」**に対する具体的な対策については、以下のポイントが挙げられます：
• OpenAIやMicrosoftのような企業は、脆弱性が報告されるとすぐにパッチをリリースしました。これにより、セキュリティ問題は修正されました。ですので、システムやアプリケーションの定期的な更新とパッチの適用が最も基本的で重要な対策です。
• Zenityの研究者は、AIエージェントがユーザーの代わりにフォルダを開いたり、ファイルを送信したりするような動きをする現在のセキュリティアプローチには限界があると指摘しています。そのため、AIエージェントの活動を常に監視し、異常な動きを検出するシステムを導入することが必要です。
3. 多要素認証 (MFA) の導入
•メールアドレスだけでアカウントを操作できる脆弱性が示されているため、**多要素認証 (MFA)**を導入することで、ハッカーが一度侵入してもアクセスを制限することができます。これにより、アカウントの不正アクセスを防ぎやすくなります。
•AIツールやエージェントに与えるアクセス権限は、必要最低限に抑えるべきです。もしエージェントが機密情報にアクセスできる権限を持っている場合、それが攻撃者に悪用されるリスクを高めます。最小権限の原則に基づき、AIがアクセスするデータや機能を制限することが重要です。
•ユーザーに対して、怪しいリンクやファイルを開かないこと、セキュリティに関する意識を高めることが有効です。ゼロクリック攻撃のように、ユーザーが何もしなくても攻撃されることがあるため、定期的なセキュリティトレーニングと啓蒙活動が求められます。
•AIツールやエージェントがどのように動作しているかを監査し、予期しない動作や異常を検出するシステムを導入することが重要です。特に、ファイルやメールを無断で送信したり、ユーザーの意図しない行動を取る場合、その挙動を警告する仕組みを持つことが推奨されます。
• Zenityのようなセキュリティ企業と連携し、最新の脅威に対する検出能力を強化することも有効です。脆弱性を早期に発見し、対応するための専門家のサポートを受けることで、セキュリティレベルを向上させることができます。
• 機密データを暗号化して保護し、万が一攻撃を受けてもバックアップから復旧できる体制を整えることが重要です。これにより、重要な情報が漏洩した場合でも、被害を最小限に抑えることができます。
⸻
総括
ゼロクリック脆弱性は、ユーザーの行動に依存せずに攻撃が可能なため、より強固なセキュリティ対策が求められます。パッチ適用だけでなく、エージェントの監視、アクセス制限、教育など、複合的なアプローチが必要です。これからはAIツールやエージェントが進化し、さらに複雑なセキュリティの問題が発生する可能性があるため、進化したセキュリティ戦略を持つことが不可欠となるでしょう。
小さいコードは結構精度がいいが、実務だとコードが膨大＋複雑なので使い物にならない、廃課金すれば結構使えるみたいな感じ
ChatGPT+Cursor+Claude+Codex+ClaudeCode でやってる、適材適所が日々変わっていく（GeminiとClineは全然触れていない）
観測できてないけどたぶんWeb陣営はもっととんでもないことになってそうではある、とは言えやはりフロントは厳しいのでは？バックもいうて厳しいけど（間違えられないし）
新規開発はだいぶ早くなりそう
個人開発するときに、公式データを持ってきてAPIとか作るんだけど、大体フォーマットが微妙なので整形するのにAIが大活躍する
今、モバイルはクロスプラットフォーム開発がどうなるかっていうフェーズなんだけど
これぶっちゃけ片方作ってからAIに投げたらもう片方いい感じに作ってくれそうってのもあるよね
その場合どっちが早いんだろう？クロスプラットフォーム vsAI駆動開発 あるいは、AIクロスプラットフォーム開発ってのもあるだろうし
混沌が訪れるね
今日はMCP（Model Context Protocol）について考える機会があった。MCPはAIエージェントが外部ツールやデータベースを呼び出すための統一インターフェースであり、従来バラバラだったシステムと言語（言語）をシームレスにつなぐ力を持っている。
例えば、営業チームがCRMから最新の顧客情報を取得しつつ、同時にスプレッドシートの分析結果をレポートに組み込むといった複数ステップのワークフローを、人手を介さずにAPIキー一つで実行できる。これにより、チームの連携速度は飛躍的に向上し、日常業務の自動化が一気に進む。
MCPが実現するのは単なる技術的な接続ではない。国や企業の枠を超えたデータ共有、異なるプラットフォーム同士の相互運用性、さらにはAIと言語モデルの知識を即時に現場に反映する迅速な意思決定基盤である。これまで数週間かかっていたデータ統合プロジェクトが、MCPを使えば数時間でプロトタイプを動かすことも可能だ。
世界中のMCP対応クライアントやサーバーは日々増え続けており、情報が集約された大規模ディレクトリとしてhttps://mcp.umin.ai が活用されている。ここには最新のMCPサーバー一覧や接続手順がまとめられており、誰でもすぐに自分の環境で試せるようになっている。
技術が進むほど、人間の創造力を邪魔する手間が増えてしまっては本末転倒だ。MCPはまさにその手間を取り除き、ビジネスも研究もクリエイティブな活動へとシフトさせる鍵となるだろう。これからの世界を変えるプロトコルとして、ぜひ注目したい。
