これは産みの苦しみ？

PM(非技術職、プロジェクトマネジメント)です。既存業務とは別にAI担当になりました(なんやそれ)。

それ以前から、アイデアの壁打ち、調査、文書作成、添削、翻訳、データ分析、あたりの、いわゆる個人業務効率化にはAI使ってましたが、今求められているのはソリューションを作ること。アプリだったりagentだったりの、みんなに使ってもらえるようなもの。

そうなると、途端に赤ちゃんみたいな状態になって、むしろ業務非効率化に。。。

いくら自然言語って言っても、最低限の技術知識がないと何か作るって大変じゃないですか？そこから調べる(もちろんAIに頼る)から、時間がかかる。MCPサーバー？エンドポイント？？いちいち知らんワードが出てきてコミュニティで大量にやり取りされてる会話のキャッチアップだけで無限に時間が過ぎてく。

社内情報やツールにイマイチうまく接続されてないから、思った通りにいかないことも多い。

結局、昨日はテスト的に作ろうと思った社内アプリを、まあなんとか3歳児くらいかな、と思うレベルに仕上げるのに丸一日費やしてしまった。。

社内ツール利用前提なので、もしかしてその性能がイマイチなのも影響してるかもしれないけど。

非技術職の皆さん、こんな感じですか？？これは誰もが通る道？？

コメント一覧

話は別ですがセキュリティやらかしてそうで怖いです

投稿者

そこら辺は、今のところ社内AIの世界に閉じててガチガチに守られてるので大丈夫かと。システムセキュリティという意味で。ヒューマンセキュリティは元々かなりケアするタイプですし。

非技術職で丸一日で形にできるなんてすごいじゃないですか！

私もAIに頼れば誰でもできるというので週末などに作ってみてますがAIが書いてくれたコードをメモ帳に貼って保存してるような次元からですよ

IPAやクラウドの高度資格いっばいもって技術わかりますみたいな顔して偉そうにしてるのに恥ずかしすぎてこんなものまだまだ人前にお出しできませんわ

投稿者

ありがとうございます！形にしたといっても3歳児レベルなので、私もまだまだです。。

資格持ってるのすごいですよ。絶対基礎知識がしっかりしてるはずです！

非技術者の立場で突然AIプロジェクトにアサインされると、とにかく新しいことだらけで全部難しいと感じるのは自然だと思いますが、実際のところ、技術的に革新的なのはtransformerベースのLLMそのもので、RAGやAgent、MCPなどの構成要素は、既存のソフトウェア技術の組み合わせや設計思想の整理であることが多いです。MCPは実体はREST、つまりこうしてWorkCirlcleを見るときにも使われている通信だし、エンドポイントもシステム間やコンポーネント間の通信するときの宛先に過ぎなく、これまでのシステム開発で普通に使ってきた概念です。

ただそれを、仕組みとして理解して自分の業務や社内環境にフィットさせるまで落とし込むのは、技術職でないと確かにハードルが高いかなと。構成要素ごとの役割と必要最低限のワードを絞って抑えると、だんだん全体像がつかめると思います。

> MCPの実体は REST

RESTという言葉を「HTTPで通信しているWeb API全般」みたいに広義に使われることはあるとは思います。

ただ、GraphQLやgRPC-web、WebDAVのように、HTTP上で動いていてもRESTの定義には当てはまらない技術も多いです。

MCPもむしろこうした「HTTPの上に構築されたプロトコルの1つ」というイメージの方が近いかなと。

MCPは、RESTのようなデータ取得目的ではなく、会話保持、ツール呼び出しの制御用途に特化している点が特徴的です。

完全に「細かいんだよ、これだからエンジニアは」で、すいません🙇‍♂️

ご指摘の内容は理解しています。このスレでは非技術職の方が対象で、MCPを概念的に捉えてもらう目的で、あえてシンプルにREST的な仕組みと表現してます。技術的にはより正確な整理もありますが、複雑さへのハードルを下げることこそが重要と考えます。

返信ありがとうございます🙇‍♂️

であれば、投稿主のpostになかったRESTという単語も避けたほうが良さそうですね。

----

MCPは、AIとやりとりするための「会話の流れ」や「道具の使い方」を決めた共通ルールのようなものです。

例えば、AIが「地図を見て」「カレンダーを確認して」「計算して」といった複数の操作を行ったり、やりとりの文脈を覚えておいたりするために、このルールに沿って情報をやりとりしています。

普通のアプリが「これをちょうだい」と一回だけお願いして終わるのに対して、MCPは何度もやりとりするような、会話の続きや道具の連携を前提にしたやり方になっています。

たぶんスレ主さんの話だと、「APIとは何か？」というところからの理解の状況かなと思いました。

数年前でいうとRailsでコマンド一発でブログがつくれた！だがここからどうしろと…？みたいな感じかなと。

どちらにしろ、やはりエンジニアが通る基本のキみたいなルートは通らないと難しいとは思います。日本の資格であれば、ITパスポートや基本情報技術者をとればだいぶ見え方は変わりそうです。

エンドポイントという用語に向き合っているAIプロジェクトを遂行している投稿者者さんに、APIとは何か、RESTとは何かまで説明する前提はこの限られたスペースではないです。MCPは登場して1年経過してないですが、API/RESTは20年かそれ以上経過している事もあり。

私が先のコメントで重きを置いたのは、MCP含め「知らんワード」とおっしゃるものの実体は、既存の技術の別の使い方・解釈に過ぎないという点です。技術的な正確さやMCP自体の説明をする事ではないです。非技術職と自称される投稿者さんに寄り添ったスタンスです。

私が言いたかったのはAPIやRESTの説明をしたほうがいいということではなく、transformer LLM RAG REST…という専門的なワードの羅列だけでスレ主さんはお腹いっぱいになるのではないかな、という話でした。

お腹いっぱいになると先が読めない可能性があるので…。

用語を並べることが目的ではなく、投稿者さんがすでにAIプロジェクトを進め、MCPやエンドポイントといった言葉に直面している前提のもと、それらの実体は既存技術の組み合わせであり、必要以上に難しく考えなくていいと伝える意図です。

LLMやRAG、RESTも今直面している構成要素であるからこそ、transformerだけが革新的であるとお伝えしました（その用語の言及は必須）。情報過多にならないように留意しつつ、本質をシンプルに伝えるよう努めてます。

投稿者

どこにぶら下がったら良いか迷いつつ…、私のために真剣に議論してくださりありがとうございます！

このやり取り自体が、すごくすごく役に立っています！

まさにその区別(既存技術の話なのかAIならではの話なのか)から、区別がつかないことがよくあります。

APIは知ってる、LLMも知ってる、RAGは最近AIプロジェクトの流れで知った、けどRESTは知らなかった、みたいな統一性がないです。

AI以前の問題なので、基礎的な技術者資格の勉強が必要そうです。