  |
はてなキーワード: AWSとは
「フロントエンド不要論」は、最近の開発現場やサーバーレス、クラウド技術の進化に関わっている人たちの間でリアルに実感されている問題です。
• React, Vue, Angular などのフレームワークがどんどん複雑化
• フロントエンドとバックエンドの分離が、**「本当に効率的か？」**という疑問が生じている
• 「最終的にHTMLを描画するだけなら、サーバーでやればよくない？」
• フロントエンドから直接APIを叩く構成では、「APIを守る」ことが難しい
• XSS, CSRF, CORSといった脆弱性に対処し続けるコストが無駄
🚩 3. サーバーレス・クラウド技術が進化し、APIの負担を減らす方向に
• AWS Lambda, API Gateway, Cognitoなどのサーバーレス技術が進化
• フロントエンドがAPIを叩くより、サーバー側で直接処理する方が効率的
• 以前はReactを使用 → ReactをやめてHTMLベースに戻した
• React, Vue, Angularを全廃
• JavaScriptなしで動的なページを実現
3. Laravel（Livewire）
4. Shopify（GraphQLでデータを直接取得）
• フロントエンドを完全分離する構成から、「バックエンドがHTMLを返せばいい」 というシンプルな構成へ移行
• APIの負担を減らすことで、開発効率とセキュリティを向上
✅ サーバーレス時代の最適解：「フロントエンド不要アーキテクチャ」
「フロントエンドを捨てて、サーバーがすべての処理を担う」方向に移行するのが最適解になりつつある。
📌 最適なアーキテクチャ
ブラウザ → サーバー（PHP, Node.js, Go） → API Gateway（Cognito認証）
📌 具体的な実装例（PHP + Cognito + API Gateway）
require 'vendor/autoload.php';
use Aws\CognitoIdentityProvider\CognitoIdentityProviderClient;
use Aws\Exception\AwsException;
$client = new CognitoIdentityProviderClient([
'credentials' => [
'key' => getenv('AWS_ACCESS_KEY_ID'),
'secret' => getenv('AWS_SECRET_ACCESS_KEY'),
],
]);
$email = $_POST['email'];
$password = $_POST['password'];
try {
$result = $client->initiateAuth([
'AuthFlow' => 'USER_PASSWORD_AUTH',
'ClientId' => 'XXXXXXXXXX',
'USERNAME' => $email,
],
]);
setcookie("accessToken", $result['AuthenticationResult']['AccessToken'], [
'samesite' => 'Strict'
]);
header("Location: dashboard.php");
}
?>
🚀 **「フロントエンドはもう不要」**という流れは、最新のクラウド/サーバーレス開発に携わる人たちが実感していること。
☑ セキュリティが大幅に向上する
👉 結論：「フロントエンドは不要」クラウド×サーバーレスでバックエンドが主役になる！
スラドと OSDN の受け入れ先募集を開始して 1 年以上が経過したが、残念ながらこのままサービス終了を終了する運びとなった。
OSCHINA は OSDN を無償で取得したものの、特に活用することができずに多額の費用を費やしたようだ。スラドはもともと OSCHINA に譲渡するのではなく、AWS 上で共存している OSDN から分離して日本企業が引き取るという話になっていた。しかし、分離する前に OSCHINA への譲渡が完了してしまい、OSCHINA 側へ正確に分離の話が伝わっていなかったため、分離の交渉は難航した。ようやく OSCHINA が分離に合意したのは 2023 年 12 月。この時点では引き取りを予定していた日本企業で一定期間事業買収ができない状況であり、OSCHINA 側は既にサービス終了の意向を示していた。
その後、OSCHINA はいったん発表したサービス終了を撤回し、受け入れ先募集を開始。OSCHINA では受け入れ先募集にあたって支払った経費だけでも回収したいとの意向を示していたが、スラドと OSDN を分離する場合のサーバー費用の比率が確定せず、応募していただいた企業の方々と交渉できないまま時間が過ぎていった。最終的にサービス終了との結論に至った理由についてはコメントを得ることができなかった。関連するドメインネームはすべて OSCHINA が保持し、将来的に新しいサービスで使用する可能性もある。
サービス終了予定は 3 月 31 日。まだしばらく時間はあるが、新しい雑談場所を決めるなり、連絡手段を確保するなりしておくといいだろう。また、スラドの皆さんは多くが既に必要なデータを確保したと思われるが、まだの方はお早めに確保することをお勧めする。なお、サービス終了時点で AWS の契約は終了せず、OSCHINA のエンジニアがサービスを停止させる予定だ。そのため、消去作業を��うまでサービス終了後もサーバー上にはデータが残されるので注意してほしい。実際の停止時刻については後日お知らせする。
末筆ではあるが、スラドを存続させようとご応募いただいた企業の方々、および募集に協力していただいたアピリッツに謝意を示したい。
ストーリー by headless 2025年03月15日 6時00分終了 部門より
身体を壊して先日ちょっと入院していたのだが、病院内ではWiFiが提供されていたので、消灯時間外の日常生活アクセスはそれのお世話になっていた。消灯時間は夜9時から朝6時までだ。
事前に「入院生活にそぐわないサイトには接続できません」という告知が為されていたので、覚悟の上で使ったのだが、Webアプリ開発者としての業務に必要なサイトとかも禁止されていたので、ここにメモしておく。
通信が禁止されていると思われるサイトに接続すると、ブラウザ側ではタイムアウトのエラーとして表示される。もちろん、それなりに待たされる。ブラウザの開発ツールの様子を見るに、おそらく TCP handshake に失敗していそう。
正常に接続できるサイトの様子を見た範囲では、HTTPS接続の証明書改ざんは行われていないようだったことから、HTTPSの暗号を解読してどうのこうの、という処理をしていない可能性が非常に高い。つまり、通信制限は接続先ドメインまたはIPアドレスによる判断で実施している可能性が高い。
また、中間的なサイトも存在する。通常2秒以内で表示できるようなサイトの表示に10秒(体感)かかるところがある。稀にタイムアウトする。
謎なのは、通信が禁止されていそうなサイトでも「待たされた挙句、つながることが非常に稀にある」ということと、curl等ではすんなりと接続できることである。
DNS設定と一緒にproxy設定が落ちてきているのであればこの挙動も理解できるのだが、手元のOSのネットワーク設定にはproxy情報が何も出てこない。ちょっとよくわからない。
もしもDNSに対するAレコード(AAAAも？）問い合わせに対してニセモノを返すという仕組みで通信制限しているのだとしたら、「非常に稀につながる」挙動にはならないはずなので、透過型proxyによって頑張っているのではないかと想像するところである。
なお、消灯時間中は全てのリクエストがタイムアウトになる。消灯時間開始直前に HTTP Request を送出して、応答が来る頃には消灯時間に入っている場合にはどういう挙動をするのか、というテストをやる暇は無かった。ｽﾏｿ
業務で使う全部のサイトを検証できた訳じゃなくてゴメンね。結局のところ仕事は携帯回線でやっちゃったから。
| ドメイン | サイトの概要 | 接続の様子 |
|---|---|---|
| hatelabo.jp | はてなの実験的サービス置き場 | すんなり |
| anond.hatelabo.jp | 増田 | 禁止 |
| ??????.hatenablog.jp | はてなブログのドメインの一つ、そして増田の中の人のブログ | 遅い |
| console.aws.amazon.com | AWSの管理コンソール | 禁止 |
| www.amazon.co.jp | ショッピング | めちゃくちゃ遅いけどつながる |
| www.amazon.com | ショッピング | めちゃくちゃ遅いけどつながる |
| ja.wikipedia.org | 百科事典 | 禁止 |
| www.php.net | プログラミング言語PHP | 禁止 |
| www.typescriptlang.org | プログラミング言語TypeScript | すんなり |
| stackoverflow.com | プログラミング質問サイト(英語) | すんなり |
| qiita.com | プログラミング質問サイト(日本語) | 禁止 |
| packagist.org | PHPのパッケージ管理 | 遅い(通常通り？ｗ) |
| www.npmjs.com | JSのパッケージ管理 | すんなり |
なお、自分のドメインのサブドメインに禁止ドメインを入れたようなもの、例えば anond.hatelabo.jp.example.com のようなドメインに対する接続可否は検証していない（面倒だったｗ）
サーバ目線で見える client IP をwhois等で調べると、某F社さんだった。AWS管理コンソールへの接続を禁止するあたり「あっ…！」と思ったり…ｗ
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 2212 | 声明文 - 脳外科医 竹田くん | dr-takeda.hatenablog.com |
| 1409 | KyotoU Channel | www.channel.pr.kyoto-u.ac.jp |
| 1393 | DeNA南場智子が語る「AI時代の会社経営と成長戦略」全文書き起こし ｜ フルスイング by DeNA | fullswing.dena.com |
| 1294 | 子供の不機嫌への対処法 - 感情の考察、日常の幸福 | kosakimomo.hatenablog.com |
| 865 | 中国で失踪 | safeguarddefenders.com |
| 822 | トップページ｜オウム真理教問題デジタルアーカイブ | www.moj.go.jp |
| 817 | 僕のタスク管理2025年版：ChatGPTとNotionでいい感じに毎日を過ごす ｜ mozlog | kannnonn.com |
| 750 | SNSで規制すべきは組織的な書き込み - 続・はてなポイント３万を使い切るまで死なない日記 | kawango.hatenablog.com |
| 665 | まだ人間が議事録書いてるの？ 日本語特化の文字起こしAI『kotoba-whisper-v2.0』がスゴいらしい | data.wingarc.com |
| 659 | 海外「日本人は深煎りコーヒーを好む」日本独自のコーヒー文化に対する海外の反応 : すらるど - 海外の反応 | sow.blog.jp |
| 639 | 自分のOSSのマルウェア入り偽物を作られたので通報した - 酒日記 はてな支店 | sfujiwara.hatenablog.com |
| 591 | 球団からのお知らせ | www.yakult-swallows.co.jp |
| 563 | NHKシステム開発・移行中断の件について | jp.newsroom.ibm.com |
| 528 | 突然Yahoo!IDが停止されてeBookJapanも利用不可になった件 - Privatter | privatter.net |
| 499 | 押井守監督が20年目の“今だから”語れる「イノセンス」の真実 そして本作を“今”劇場で観る意義とは？ | anime.eiga.com |
| 481 | 「うちの鍋は、もうこれだけでいいよ！」夫に言わしめた鍋は「2つの調味料」を入れるだけ。締めラーメンまで絶品 ｜ kufura（クフラ）小学館公式 | kufura.jp |
| 474 | 当社に対する訴訟の提起について ｜ 重要なお知らせ ｜ 株式会社サンリオ | corporate.sanrio.co.jp |
| 470 | NOT A HOTELのビジネスモデル - 続・はてなポイント３万を使い切るまで死なない日記 | kawango.hatenablog.com |
| 464 | なぜあなたのウェブサイトは遅いのか | mizchi-20250213-devsumi.pages.dev |
| 457 | map / filter などの高階関数よりも古典的な for文の方が読みやすいと感じるあなたへ | gakuzzzz.github.io |
| 426 | 生成AI時代の音声入力ツール：SuperWhisperのすすめ - うみのーと | umiyosh.hatenablog.com |
| 420 | 音楽の新陳代謝が止まって「ダサい」がなくなったことの功罪 - 森の掟 | guatarro.hatenablog.com |
| 414 | Rustで進化するPayPayのスケーラビリティ | blog.paypay.ne.jp |
| 407 | マキネッタ、完全に理解した - ちなみに | blog.nishimu.land |
| 370 | 【動画】田代まさしさん「覚醒剤はフジテレビのあるADから『いいのありますよ』と誘われた」 | sn-jp.com |
| 369 | 死神 - ヤマシタトモコ / 死神 ｜ OUR FEEL（アワフィール） | ourfeel.jp |
| 345 | 【トラブル】成田空港会社が契約終了を警告、「みんなで大家さん」に借地リスク浮上 | nfm.nikkeibp.co.jp |
| 344 | NotebookLM Web Importer - Chrome Web Store | chromewebstore.google.com |
| 319 | draw.ioでレイヤーを使ったらAWS構成図が捗ったお話 | tech.anti-pattern.co.jp |
| 313 | SQL道場 - SQLの実践的な学習サイト | sql-dojo.com |
コンニチハ、オイソギデスカ
非常に良くない生成AIビックウェーブが来ちゃったんで憂鬱な皆さんこんにちは。
生産性が上がるとか効率が良くなるとか宮仕え（みやづかえ）だと、福音どころか地獄ですよね。
ぼちぼち日経新聞がAIエージェント導入で他社に差をつけようみたいな記事を書く頃だと思うので、備えましょう。
まずいつも通り前提からな。
ここまでは前提な。
DeNAがさ、既存事業３０００人の従業員を半分で回すようにするって目標立てたじゃん。つまり、１５００人の業務負荷は倍になるのよね。
倍になったら普通は回らないところ、生成AI使えば倍でも回るでしょ？って言われてるわけだよね。
アレが非難されずに、素晴らしいとか、（諦め半分で）まあそうなるよねって言われてるのが全てなんだけどさ、シンドイよね。
生成AIで業務効率化されてハッピー、毎日定時で何なら毎週金曜日はカジュアルフライデーで飲みながら仕事だ〜、とはならないんだよ株式会社は特に。
経歴詐称して潜り込むってウッソだろというホワイトなみなさんは、パワポ作るとかペアプロするとか輪読会するとか適宜置き換えてください。
新規にプロジェクトに入った時に、なんか資料もねえし、コードをぼちぼち読みながら、急ぎでもクリティカルでも無い部分を書いてレビューしてもらって修正してマージして、
みたいな作業が消えます。この辺もう既に出来るから生成AIで。
というか、すでにこのへん置き換えて楽してるやついるだろ。そうそこのお前。
今までも、華麗なる経歴とやらの人物が作り上げていったコードを保守運営する時に相当キッツイことになってた人は多いでしょう。
ほら、新規事業でも何でも、とりあえず動いて売り上げ立てた人が偉いのはその通りなんだけど、それを直すのは大変なのよね。実運用の時には大抵転職してて居ないし。
でもさ、まあ言うても立ち上げの時期に技術的負債とか考える余裕もなく速度重視でゴリゴリ作った人の立場になってみると、まあ仕方がなかっただろうな、と感情移入もできる。
これが、スーツが「動くものは作っておいたから簡単だよね？」とかAIの作ったクソコードの山をギークに渡すようになるんだぜ。腹立つことにハンパに動くやつを。
今までも「AWSでポチポチしたらすぐでしょ？」とか言うクソスーツは居たけど、実際に手を動かしてモノ作ってくるスーツは概ねまともだっただろ？
金払えば使えるようになったから。身も蓋もないけど。
あえて言えば、簡単にお試しできるようになった、と言うところが本質的な部分です。
以前からChatGPT4とかAmazon BedRockとか使ってた人ならわかると思うんだけど、別に今までもできたんだよね。
ただ、全自動で回せるパッケージングとしての品質がそれなりに高いので、お試しのハードルがぐっと下がった。
これ、APIと簡単なスクリプトで以前から自動化できてたんだよね。（やってたやつは俺以外にも割といると思う）
決まったフォーマットで出力してもらって、そっから切り出して実行して、出たエラーをもう一回入れて修正して、動くようになったら止める。
出来上がったコードとそれまでの途中経過を全部まとめて入れて、最初から出来上がったコードにするためのプロンプト考えてってところまでをワンショット。
あとは、出てきたコードとプロンプトを眺めて良さそうなら採用する。この繰り返しでめっちゃ楽出来てた。（壊れたらDocker建て直せば良いし）
これを、そう言うスクリプト書いて整備して良い感じにGitで管理してたお手製のツールを大手が良い感じに作り上げてきちゃった感じ。あーあ。
特に速度は分かりやすく効率に影響するので、自営業とかプレイングマネージャとかは、今導入しても元がとれるだろうね。
じゃあ、なんでCline（とそれに類似するツール群）に全部賭けない方が良いかというと、まだ過渡期の技術だから。
ツールのオペレーションに全振りして、大手が改良版出しちゃってオペレーターとしての職が無くなった経験、あるでしょ？
今Clineで不満に感じてることとか、プロンプト調整しなきゃなあみたいなところ、全部自動化できるでしょ。
一年保たないと思うよ。
そりゃあ人間雇ったら高えのはわかるけど、単一障害点は怖いぜ。
みんな、生成AIのAPIが逆鞘だろうことはわかってるよね？急に明日から10倍に値上げされて耐えられますか？
今、OpenAPIのたけえのだってたかだか３万ぽっちだけど、あれに毎月３０万円だせって言われて耐えられる？９０万なら？SLAも怪しいのに？
そう言う時、「じゃあやめて人間雇えば良いじゃん」って言った時に、話聞いてくれる相手がいて欲しいよね？不義理しないでおこう。
同じように、新人はちゃんと育てるべきなんだけど、多分聞いちゃくれないから、そう言うところはドンヅマったら転職しよう。
（経営側にいる人間は、安易にAIエージェント＋中堅に頼った場合、中堅がその会社の急所になるのは抑えておこうね。引き抜かれて崩壊する組織は脆弱だよ）
IBMが訴えられてるよね。アレ、AIエージェントあったら回避できてた？
俺は無理だと思う。
試験導入しますね、と言ってガンガン使ってコストをあげましょう。予算が尽きるまで使えば概ねそこまでです。
また、AIエージェントを導入しつつ、動作を確認したり、自社のどこに活用できるのか見ておくのはとても役に立ちます。
具体的に言うと、ググったコマンドを片っ端から試すような新人が入ってくると思ってください。
その新人は、概ね１０００行以下のコードなら即レスしてきます。変えるなと言った箇所もたまに結果を出すために変えたりします。
そして、その新人相手の知見はおそらくそんなに長くは持ちません。何故なら我々が不満に思う箇所は改善されてお出しされるからです。
そのため、Cline(やそれに類似するツール）の知見を貯めよう！なるほどこんなプロンプトを与えてやれば良いのか！みたいな試行錯誤はやめた方が無難です。
今後も解決されないであろう部分を切り分けるのに留めましょう。
超具体的に言うと、AWSのコマンドを片っ端から試されたりすると、すげえ課金されるやつ、あるよね。でもそれちゃんとポリシーで制限できるよね。
人間相手に常識で縛ってたことを、ポリシーで縛るようにちゃんとしておこうね、ミスったコードで高速にIaCお試しされるとす��えことになるよ。
（なりました）
仕様検討にはo1 pro modeが（推論が強いから）、コーディングはClaude 3.5 Sonnetが（コーディングに万能に強いから）、コードのデバッグはo3-mini-highが（コードの解析に強いから）という時代から、Claude 3.7 SonnetのAPIセットしたClineで全部お任せして試行錯誤した方が結果的に効率が良くなってます。
今はPythonやTypeScriptのように、基本的に大量にコードが存在して生成AIを開発する側が良く使うコードの性能が高くなっています。
（ただ、相当にマイナーな言語であっても、別に学習に支障があるとは思えません。おそらく単に優先順位の問題です）
「AIコーディングについてのレポートをあげて、稟議を通すための理由もつけておくように」みたいな指示は、ChatGPTのDeepResarchに振って、上がってきたレポートをそれっぽく書いておけば良いです。
なお、ChatGPT４.5があんまり性能が出てないと聞いてがっかりしている人に朗報ですが、4oから4.5に変わったことで、相当に性能は上がっています。
具体的に言うと、「クソみたいな上司からムカつく指示が来てどうにも収まらないんだけど、以下の内容を相手が納得するように書き直してくれない？」みたいなのに、すごい親身になってそれっぽい感じに書き直してくれます。人間力は多分俺より上です。
アメリカのトランプ大統領は自動車の関税を上げるらしいし、それならこちらも何かできるんじゃないかということで、「デジタルサービス税」というのはどうだろうとAIといっしょに考えてみた。
案としてはシンプルで、日本でのデジタル売り上げが1000億円超える外国企業に追加で5%課税するというもの。
まあ、アメリカは大切な同盟国なので名指しを避ける感じで、対象は「すべての外国企業」を対象となるが、実際はGoogle、Apple、Amazonあたりが引っかかるように設定すればいい。
Apple: 日本での売り上げ、iPhoneとかApp Storeで年5000億円くらいあるとしよう。5%なら250億円。
Google: 広告とYouTubeで1兆円くらい稼いでるとして、5%で500億円。
Amazon: ECとAWSで7000億円くらいなら、5%で350億円。
合計で年1100億円くらい税収が見込めるはずだ。
たとえば、今「高額療養費の自己負担限度額上げようか」って話が出てる。でも1100億円あれば、限度額上げなくても済むくらいの支援金に匹敵する。年500億円くらいで医療費補助拡充できるって試算もあるから、余裕でカバーできる。
ほかにも、たとえば保育園の待機児童ゼロにするのに年200億円くらいかかるって言われてるから、1100億円あったら全国の保育所増やしてまだお釣りがくる。災害復旧とか、インフラ補修とかにも使えるし、地味にデカい額だ。
税金は企業に「日本での売り上げ申告してね」って自己申告させて、怪しかったら監査入れるくらいのゆるさでいい。
一方でアメリカが日本に対して関税をさらに上がるなら、じゃあデジタルサービス税を10%に上げようかなと交渉に使えるカードにもなりえるだろう。
もちろん、これは国内企業へのダメージがないわけではない。その分appleやgoogle、amazonの電子取引の値段が上がるだろう。
ただ、できることなら外資のサービスにがっつり依存するのではなく、国内サービスや新興サービスへ目を向ける機会になるかもしれない。
活発にリクルート活動を行っているようだから、入り込んでいるというより闇落ちという方が正しいのかもしれない。
一昔前とは違い単純な利害関係のみの関係で、人種や国籍関係なく存在していて、日本人にも数人マークされている人物がいるとか。
私も知っている人という話だった。
正直わからなくもない。
なにせ一般的な経済犯罪で得られる額とは文字通り桁が違う。能力がありそれなりの人生を歩んでいる者にとって数千万では人生賭けるに値しないが、数億、数十億となると話は変わるのだろう。
先日2200億の被害にあったBybitは、インフラに侵入された痕跡はなかったが連携しているウォレットサービスが侵入され、悪意のあるコードへ差し替えられウォレットの移動時に抜かれたという。
AWSとS3バケットにアクセスできるマシンが墜ちたらそりゃどうしようもないけど、だからこそ厳重に守るべきなのにセキュリティも内部統制も緩いからどうしようもない。
日本中で使える画期的なWebシステムを作りたいと熱く語ってくれた。
しかし彼は世の中のWebサービスを何も知らなかった。AWSもGCPも知らなければ、Xやメルカリも使ったことがないという。
いったいどうやって何を作るのか、私には皆目見当がつかなかった。
さくらがダメなのはまず知名度が圧倒的に足りないこと。さくらがクラウドやってるなんてのはエンジニアでも知らない。むかーーーーーーーしさくらのVPSが流行ったのを知ってる人が老人にいる程度で誰もさくらなんてそもそも名前を知らないのよ。バニラを見習いなさい。さくらの街宣車を出すのよ。
次にAndrej KarpathyにあんたらのGPUクラスタをタダで使ってもらうの。これでfoot in the doorは完璧よ。
そしてあんたたち給料を最低3倍にするのよ。日本人に限らず世界中から最優秀層のエンジニアを雇いまくりなさい。株もたくさんあげなさい。今アメリカの採用市場は冷え込んでるからチャンスだわ。
えっ、増田が考える『自己責任』は下記じゃないの？下記はコピペだし他に読み取りようがなかったが？
これは増田の持つ主義だから正しいも間違ってるもないぞ。ただ、ワイは賛同しないってだけ
改めて、『お前の属性の問題じゃなくて、お前のやる気の問題だろ』『お前の人生はお前自身が意味付けろ』って言ったら、
ブチギレるんだろうなって思うばかり
もう一度言うけど、自己責任ってのは、単なる能力主義・Winner takes all ／All or Nothing の話だぞ
もう一度説明するけど、自己責任ってのは、単なる能力主義・ Winner Takes All／All or Nothing の話は、突き詰めてるとかではなくて、単なる現実のビジネスの話
頑張ったなんてお気持ちに価値なんかない。自己責任を唱えるなら、現実（市場の冷酷さ）も受け入れよう
