【ネタ記事】全国配信サービスをサービス停止まで追い込んだ

f:id:exceed-yukikaze:20251107220118j:image

本記事は某有名アドカレみたいに書いてみたらどうなるのかを妄想した記事になります。

また、やや虹ヶ咲第二章のネタバレになります。

 

 

 

 

 

予兆はあった

後々ユーザーからヒアリングしたところ、「起動までやや時間がかかった」「画面遷移の途中で動作が遅くなった」ということから、この時すでにシステムに異変は生じていました。

トラフィック量は確かに多かったですが、アラートが発砲されていなかったこと、一時的なアクセス過多によるものと思い込んでいました。

あとから見返すとトラフィックが増加傾向にあり、すでに構築時のシステムの許容範囲をこえつつありました。

 

その日は突然に

あるユーザーが配信をし、その動画が人気になったところ、数日しないうちにアプリへのアクセスが不可能になった。ファイルオーバー等の機能もむなしく、サービスは終了となった

 

影響範囲

ライブ配信

関西圏、沖縄にいる女子高校生の配信希望者(数百人から数千人を想定)

・閲覧者

全国(女学生を中心とする一般ユーザー)

 

何がいけなかったのか

・ユーザーアクセス想定数が耐えられなかった

こちらが大まかな理由です。構築当初はこのぐらいの同時アクセスを見込んで配信用のサーバーを建てましたが、気づいた頃には同時アクセスを捌ききれないことになってました。

 

・(妄想1)スケールアウトする構成になってなかった

最大アクセス数を想定して構築したため、これ以上スケールアウトしての運用は厳しい状態にありました。(多分オンプレ構築だったらこうなってた)

 

・(妄想2)構築・運用費を削減するためにサーバーとDBを共通のものにしてしまった

ライブ配信用の書き込み処理とアーカイブ検索などの処理を一つに集中させた結果、耐えられなかったのだと思います。他にも共通で利用していた部分もあり、結果として1台あたりの負荷が高くなりすぎたものと思います。

 

と、妄想でアレコレ書いてみたけど

自分が担当者だったらこんな悠長にしてられないですし、最終的にサービス終了まで追い込んでるんですから胃がキリキリしそうな感じですよね。

あくまで耐えられなさそうな構成とか規模にしてる妄想なので、大手とか(それこそYouTubeとかニコニコ)なら案外いけてたかもと思っちゃいました。

 

じゃあこんな構成なら事故は防げた?

あんまり配信とかの構築みたことないんで、某ユーザーグループの資料とかハンズオンをみてたんですが、こういうのならいけたのでは?と書いてみます。

あ、初心者です、マサカリはやめて…

・そもそもサーバーとDBは処理を分ける

そもそもアーカイブデータをDBに放り込む、というのはありえないでしょうが、念の為。配信サーバーとアーカイブサーバーの処理を同一にするのではなく、URLとかで振り分けてしまえば負荷はぐっと減ると思います。

 

アーカイブはとっととS3にいれる

ライブ配信されたデータを裏でS3に入れてしまえば配信サーバーは無事なら気がします。分ける以前の問題かなと。

 

AWSなら Media Services使えば?

SO RE NA

 

それにしても虹ヶ咲学園はなぜ配信できたのか

すごいですよね。1日で配信しています。ドローンからのリアルタイム映像とかはさておいて、これらの配信サービスを自前で持ってたってことですよね。

SIFの頃につかってたものを流用してるってことはオンプレかクラウドか、何かしらの形で耐えられるものを持ってたんでしょうかね。

アーカイブは見れなさそうなのでリアルタイム配信のみみたいですが、授業とかで使うものに相乗りしてるのかな。

 

案外調べてて楽しかった

映画館で聖地の情報メモりながらこんな妄想をし続けてた自分はどうかと思いますが、案外楽しかったです。

 

参考

https://aws.amazon.com/jp/blogs/news/jpmne-fujitv-introduces-unified-content-management-system/

https://aws.amazon.com/jp/cdp/cdn-live/

攻撃して学ぶ!全エンジニアが知っておきたいAWSセキュリティ上級編をうけてみた

問題内容とかはシェアしないようにとのことなので、感想だけ。抽象的な内容になってしまいますが、ぼかして書いているのでご容赦ください。

 

CTFとはなにか

www.nri-secure.co.jp

最終的に文字列を取得すればいいというゴールにむかって解いていく内容になります。

今回の問題のレベルは世界大会の中級ぐらいの難易度だったそうです。

 

内容について

AWSの設定ミスから探っていくというので、とあるページから攻撃を仕掛けていくものでした。

取得するflag.txtがどこにあるのかを探していくんですが、認証の設定ミスから探っていくというやり方で本来であればアクセスできないように設定しているものを見つけることができました。

 

こういうのを使えば可視化できるんですね。はじめてしりました。

www.jwt.io

 

感想

僕は途中でどうするんだっけ?ってなりましたが、解説をきいて納得しました。CLIコマンドが思い出せなくて生成AIを使って行きましたが、AIの利用自体は全然問題ないらしいです。

IAMとか認証周りの設定って使わないユーザとかなら設定が甘くなりがちですが、なんらかの形で情報が流出した場合にこうやって攻撃できるんですね。

ちゃんと認証とか権限について見直そうって思いました。

 

supporterz-seminar.connpass.com

CoLab Conf(コラコン)に参加してきました

f:id:exceed-yukikaze:20250714170907j:image

サポーターズCoLabのテックイベントに参加してきました。何度か交流イベントには参加させてもらっているんですが、テックイベントは久しぶりだったので楽しみにしていきました。

U35なのでギリギリ??の枠でした。

【!現地参加枠あり!】CoLab Conf(コラコン)【U35限定テックカンファレンス】 - connpass

 

以下は聞けたものの感想です。Speakerは敬称略しております。

OPセッション U35エンジニアの生存戦略 -AIの進化とキャリア-

Speaker:上野山 勝也,佐藤 裕介, 鈴木健太

初手からAIとの付き合い方のようなところを話していました。とにかく変化が早いこと、AIにできることや求めることが段々変化してきており、そこにどうついていくか、自分のコアとなるものをどう持ちながらやってくのかという話でした。

面白かったのがMicrosoftIBMを抜いた理由の話で、HWがコアとなる当時はSWに対しての価値観が異なっており、あとはご存じのとおりSW全盛期になったときに技術差ができてたってところですね。

コア部分が変わってくる潮流に合わせないとついていけなくなるっていうわかりやすい例えでした。

 

アウトプットはいいぞ

Speaker:ラムダ, ロッシー

科学的なことやくだらなことを動画に投稿していて、その面白さやくだらないというのが変に足かせにならないアウトプットをし続けられるという内容。また、アウトプットへの障壁やリテラシーについても話していました。確かにめんどくさいと思った瞬間にやめよってなるので、アウトプットすること以外のめんどくささをどう取り除くかは重要ですね。

あとスライドはSDGsらしいです(何割かはあえて伏せます)

 

交流時間(というなの休憩)

お菓子やコーヒーを飲んだりして休憩していました。この時間にむかーしお世話になった人と話せたので楽しかったです。

 

f:id:exceed-yukikaze:20250714170905j:image

会場はとても綺麗でした。羨ましい。

 

競プロは実務でどう生きるのか?-競プロ的思考の実務応用編-

Speaker:kenkoooo,武田 源生,高橋 直大

参加者全員が競技プログラミングを経験してるという面白い状況の中のセッションでした。

競技プログラミングそのものの内容は業務に直結しづらいけど、そこを解くために培った考え方や抽象化という部分は間違いなく業務に生きてるとのことでした。

確かに日本語の問題文からどうコードに落とすかとかは課題解決の方法を探すのには役立ちますしね。(再開しようかな)

 

ひろゆきだけど何か質問ある?

Speaker:ひろゆき

f:id:exceed-yukikaze:20250714170911j:image

学生向けイベントではオンラインで何度も出演しているひろゆきがまさかの来日をしていた(表現があってるのか?)ので、急遽くることに。ほぼ目の前にいたので笑っちゃいました。本当に喋り方も仕草もあんな感じなんですね。

さて、論破王とか色々と評価はありますが、エンジニアとしてのひろゆきは比較的優しく、1人だけ「・・・ってどう思う?」となったときは若干会場がざわつきましたが、答えについては比較的その人にアドバイスされるような感じでした。

 

質問の内容にたいして「えーと」とか「あー」みたいな間延びがなく、即答するのが印象的でした。多分聞いていながらサクッと答えられるようになってるんでしょうね。ここは見習いたいところです。あと利用できるものは無料で徹底的に利用する考えいいですね。

面白かったやりとりをいくつかのせていきます。

 

Q.まともなコードを書ける人は?

A.大前提として頭の中で設計書から完成して自走できるような人がまともなコードを書けるという人。そういう人はAIが出した答えに対して修正をすぐ加えられる。今の人はAIありきでコードを書く人が増えていくので、シビアな部分が求められるエンジニアは生き残ると思う。

 

Q.競技プログラミングを今からはじめるのってありですか?
A.ゴルフを始めるのと一緒でいいんじゃないんですか?趣味のポジションで残り続けると思います。あとやってる人にいいエンジニア多いのでコネ作るのでありなのではないか。

*ちなみに質問者はAtCoderで有名なちょくだいさん。なんだこのやり取り。

x.com

 

スポンサーブースはキャリア以外の話題で盛り上がれた
f:id:exceed-yukikaze:20250714170914j:image

テックイベントなので来ている人もそれなり以上に技術が好きな人なので、採用とか関係なしに話をしていました。AIへの関心が特に高いところばかりでしたが、それに伴ってセキュリティも結構重要なんだなーってのが収穫でしたし、医療系の難しさもしれました。

1社ずつ書きたいんですが、どれも面白かったとだけ。長くなりそうですし。

 

 

残りのセッションはアーカイブ

休憩やスポンサーブース巡り、セッションかぶりで聞けなかったものは結構あるので、あとはアーカイブをみて振り返るとします。

登壇者があまりに豪華すぎるので、ちょっとは分散させてくれないですか()

 

久しぶりのテックイベント

仕事がいそがしかったり(のせいで就業後のイベントをキャンセルする羽目に)、土日はなぜかよくわからないですが、一生懸命走る動物を応援したり、同窓会関係のものがたてこんだり、コミケ前後は原稿で大変だったりと言い訳すればいくらでも出てくるんですが、テックイベントの参加はいいですね。

あとOver35になったら違う形で参加したいなって思いました()


ちなみにガラポンの景品は代表の楓さんサイン本もありました。本を持っていけばよかった()

www.amazon.co.jp*非アフィリエイトリンクです。気になる人はタイトルだけ検索してくださいな。

 

AWS Summit2日目に参加する人へ

AWS Summitがはじまりました。セッションの登録を事前に済ませていると思いますが、当日こんなふうに動いたほうがいいってものをメモとして残していきます
(随時更新予定)

 

事前用意

AWS Summitへの登録

https://aws.amazon.com/jp/summits/japan/

これがないと詰むので事前にしておくこと。当日受付もできますが、開始まではなるべく時間を削りたいのでさっさとやりましょう。紙は印刷していかなくても大丈夫ですが、もっていっても困りません。

 

名刺

受付時に求められます。「あれ?どこいった?」みたいなことを防ぐためにも事前に用意を。

 

Credlyアプリ

今回は事前にステッカーやノベルティをもらうことができます。Webページから見せるのもできなくはないようですが、基本的にはアプリを求められます。

f:id:exceed-yukikaze:20250625093049p:image

僕はあらかじめ分けておいた。

 

よく寝ること。早起きすること。

開始してからいいや、だと後悔しそうなので早く起きましょう。前日にガンダムなんてみるのは特にだめです。

 

リュック(ガチ)

なんだかんだでノベルティもらえます。クッションを手で持って帰りたくないですよね?やや大きめのものを持っていきましょう。

 

基調講演までにやっておくこと

とにかく早く起きて並ぶ

基調講演を生でみたい人は頑張って早起きしましょう。指定席が必要になりますので、早めにいかないとなくなります。少なくとも1時間前にはなくなっていたので、2時間前とかがベストです。

なお、サテライト会場でも配布しているので、基調講演取れなかったからと諦めるのは早いです。クッションガチ勢はどこまでいるんだ。。。

昼食券とクッションは30分前でも余裕があるように感じましたが、Day2での保証はありませんので()


モーニングドリンクを確保
f:id:exceed-yukikaze:20250625093011j:image

朝から飲料(ノンアルコール)を1本無料でもらえるとのことなので、流れるように生きましょう。向かって左側、基調講演の会場です。

 

認定グッズを確保しておく
f:id:exceed-yukikaze:20250625093004j:image

前回は認定ラウンジ行くのに基調講演を途中で抜け出して向かって諸々を確保していましたが、今回は事前にもらうことができます。All Cert向けのジャケットは受付左手すぐ、認定ステッカーは向かって右側のサテライト会場入口付近です。

 

それでは楽しんで行きましょう

f:id:exceed-yukikaze:20250625093008j:image

貴重な話を2日間にわたって聞ける会なので、十分に準備して楽しんでいきましょう。

 

なお幕張メッセのコンビニにはエナジードリンクとゼリーが多数置かれています。なんとしてでも気合を確保したい人はこれらで乗り切りましょう。

Gemini 2.5が無料でも使えるようになったので、ServicveNowのスクリプトを生成してみる

f:id:exceed-yukikaze:20250401163154j:image

Googleには課金してるので、自分はそもそも使えますが、無料ユーザでも利用できるようになったGemini 2.5を利用してみることにしました。

gemini.google

 

 

コーディングの生産性を向上させる・・・らしい

というわけで、自分にとって唯一?といってもいいぐらいしか使わない、Javascriptについて聴いてみることにします。

まずは適当にプロとしての意識を持ってもらうことにします。

あなたはServiceNowに関するプロであり、コーディングを実装してスクリプトを生成することにたけています

 

Gemini 2.5の結果は以下の通り

私はServiceNowプラットフォームに関する広範な知識を持ち、特に以下のようなコーディングやスクリプト生成に関するご要望にお応えできます。

  • スクリプトの生成:
    • ビジネスルール (Business Rules)
    • クライアントスクリプト (Client Scripts)
    • スクリプトインクルード (Script Includes)
    • UIアクション (UI Actions)
    • UIポリシー (UI Policies) スクリプト
    • スケジュールジョブ (Scheduled Jobs)
    • ワークフロースクリプト (Workflow Scripts)
    • Flow Designer スクリプトステップ
    • GlideRecord, GlideAjax, GlideForm (g_form), GlideUser (g_user) などの主要なAPIを利用したスクリプト
  • コードの説明と解説: 既存のスクリプトが何をしているのか、どのように動作するのかを解説します。
  • コードの改善提案: より効率的で、ServiceNowのベストプラクティスに沿ったコードへの改善案を提示します。
  • デバッグ支援: スクリプトのエラーや意図しない動作の原因特定をサポートします。(実際のインスタンスでのデバッグはできませんが、コードレビューやロジックの検証を通じて支援します。)
  • APIの利用方法: 特定のServiceNow APIの使い方やサンプルコードを提供します。
  • ユースケースに基づく実装アイデア: 特定の要件を実現するためのスクリプティングアプローチやアイデアを提供します。

 

優秀と言われたClaude Sonnet 3.7はこんな感じ。

ServiceNowについてのご質問やスクリプト実装のお手伝いができます。ServiceNowプラットフォームにおけるカスタムスクリプト開発、ビジネスルールの実装、UIポリシー、クライアントスクリプト、サーバーサイドスクリプトなど、さまざまな側面でサポートが可能です。

具体的にどのような内容でお手伝いできますか?例えば:

特定の機能を実装するためのスクリプト
ワークフロー自動化
インテグレーション開発
パフォーマンス最適化
ServiceNowのベストプラクティス
ご希望の内容をお知らせいただければ、詳細なガイダンスやコード例をご提供します。

 

さて、実際に何をしてみようかというところで、ServiceNow Incidentに対して少し追加をしてみることにします。

インスタンスはYokohamaです。

 

質問

ではServiceNowのインスタンスに以下の機能を実装してください。

・テーブルはインシデントです

・画像のAssignment Groupはよく空白になることが多いです。一方でAssigned toは必ず入力されます。

・Assigned toが所属しているグループを自動で検索し、Assignment Groupフィールドを自動で埋める機能を実装してください。

Business Ruleあたりを選択してからsys_userテーブルから参照してくる、みたいな流れが答えです。

 

では見せてもらおうか、自社最高の賢さとやらを

Gemini 2.5

長いので画像で貼ります

コードは以下

 

Sonnet 3.7

コードは以下

 

実行結果

Gemini 2.5

スクリプトは貼り付けるだけなので省略します。

ビジネスルールもですが、ServicveNowはスクリプトの実行条件をGUIで設定します。ここをミスるとコーディングが正しくても絶対に動きません。

 

Saveを押すとしっかりと変わっています。

 

Sonnet 3.7

「(current.assignment_group.nil() || current.assignment_group == '')」とありますが、GUIではほぼこれでOKです。

 

うーん、1発ではうまくいかなかったですね。

 

生成結果の比較

コードは似たりよったり

まあ、想像していたことなのですが、コードは似ていますね。といってもこの辺はスクリプトを実装するあたり、例として登場しがちなので当然と言えば当然ですね。

どちらかというと、Sonnetが生成している「userGr.addQuery('user', assignedToSysId);」のほうが見覚えあります。

 

OOTBで一発でだせたのは大きい

こういう場合ってだいたい1回では出せずに修正かけるのですが、Geminiではすぐに動きましたね。意外でした。

 

両方ともGroupを変更される条件はなしで出力

これは指定したからなのですが、かりにGroupが入力されていた場合はうごかないスクリプトになりますね。まあ、前提条件を変更すればいいだけなのですが。。。

あとは両方とも、複数Grがある場合についての記載はありますね。この場合は除外するなり、優先条件をつければいけそうです。

 

わかりやすさはGemini

設定するときにスムーズにできたのはGeminiの方でした。日本語でカラム通りにできるのは大きいですね。

設定内容の解説もこのあとについていますし、使いやすさはこちらが上でした。

 

もうちょい実用的にしたい

追加で条件をつけてみます。

先ほどの内容に以下の条件を追加してください

・Assigned toは変更していなくてAssignment groupが空白であれば実行できるようにしてください。

・Assignment groupで対象がdouble_checkerにも入っている場合、除外して次のグループを入力するようにしてください

 

When to runはほどんど変化させなくてもよいですが、スクリプトだけ変更しました。ちゃんと動くのは本当にありがたい。

 

無料でもつかえるの本当に助かる

筆者はGoogleに課金済

コードについてはCursorが有名ですが、SaaSはコード書くだけでは解決しないので、こうやってGUIでの設定項目も出てくるのがありがたいですね。

Notebook LMでも随分と使えるようになりますが、ソース入力を考えるとこっちが手っ取り早いのでいいですね。

 

motsu-log.hatenablog.com

 

 

今から追込む生成AI情報キャッチアップ:超概要と対話型AIサービスを使ってみる

f:id:exceed-yukikaze:20250301010903j:image

日々進化する生成AIのネタはエンジニアにとって日々血眼のごとく拾われており、やれ新モデルがでただの、どこそこでの新サービスがリリースされただの追うだけでも1日が終わりなそうな状態です。

一方で非エンジニアの人と話すと生成AIってGrokとかChatGPTとかぐらいしか知らないというのもよく聞きます。

 

これから生成AIとは全員が付き合っていくことになりますし、使わないということはあり得ないと思います。一方で何使うのか何していけばいいのかわからんというのもあるので、自習も兼ねて生成AIについて書いていこうと思います。

 

第一弾はみんなだいすき対話型AIサービスを取り上げます。AI検索もこちらに含めるケースもありますが、ざっくり書いたつもりでもかなり長くなったので分割することにしました。

 

この記事は2025年に書いたのでいつか古すぎる情報になると思いますが、現状での最新のものをまとめていきますので(マサカリなげないで)ご容赦を。。。。

 

あまりにも読むのが面倒な場合、「暴論」という非エンジニア向けな本当にざっくりと書いたものがあるのでそちらを見てください。

 

TL;DL

暴論:とにかく生成AIを使いたいならChatGPTで、課金もモデル選択もプロンプトも特にいらないです。

 

生成AIが普及した超ざっくりとした概要

この辺はいろんなサイトや書籍でまとまってるので詳細は省きますが、GPT-3が公開された2020年からパラメータ数と呼ばれる学習中の最適化に必要な変数が急激に増加し、より複雑な学習(例でいうと自然言語と呼ばれるみんなが良く使うもの)が可能になったことやChatGPTというのがすごそうというとこから一気に普及していきました。

 

ChatGPT(OpenAI社)

生成AIの代名詞といっても過言じゃなくなってきたもので、いわずもがなというサービスです。

バランスよく使えるので、とりあえずどれを使えばいいのかわからないという人に一番おすすめしています。

なお、GPT-4.5も発表されたので、描いた当初から記事が古くなりました()

 

モデルの命名規則ですが以下の2つです。

GPT:テキスト生成でいわゆる自然言語的なものです。

oシリーズ:GPTモデルよりもSTEM分野に特化している。

 

モデルについて

暴論:おとなしく4o使え

 

無料ユーザが使えるのは3つです

GPT-4o(一部制限有)

GPTシリーズの中で推論能力や精度を向上させたもの。画像の添付の枚数や文字数の制限、連続したメッセージのやり取りの制限はありますが、ごく普通の使い方であればこちらで十分です。

画像も使えるようになったのは大きいですね。

GPT-4o mini

4oの軽量版で4oよりも制限なし使えますが、ある程度制限はかけられているみたいです。高速仕様なので、APIのレスポンスとかを気にする人はこちらむけです。

o3-mini

oシリーズの軽量版で、無料ユーザーでも利用できます。数学や論理的推論に特化した設計がされており、STEM分野のタスクに向いています。

oが推論なら4o,o3はどっちがいいのかという話ですが、最初に書いた通り、バランスを求めるのであれば4o、STEM分野と呼ばれる「科学」「技術」「工学」「数学」に特化し、複雑な問題の解決はo3がよいです。

 

有料のユーザはこちらも利用可能ですので、簡単な紹介程度に。

o3-mini-high

o3 miniよりも軽量化、応答速度の向上、コスト効率の向上をしています。

o1

oシリーズではあるが、幅広いタスクや汎用的に利用可能です。
4oとの違いは推論の不可さや応答速度、正答率、STEM分野へより適性があるといった感じです。

o1 pro

o1から大規模プロジェクト向けのものやより複雑なもの、教育研究への用途に優れています。

 

参考

platform.openai.com

 

Claude(Anthropic)

他と比較して長文処理や要約といったところが優れています。長いコンテキストを保持することができるので、文脈理解力の部分が高いです。

名前の由来はそれぞれ詩や作品に関するものを当てています。

 

モデルについて

暴論:おとなしくSonnet使え

Claude 3.7 Sonnet

2025年2月リリースの最新モデルで、3.5 Sonnetよりも推論能力が強化されております。

汎用的に利用できるモデルで、特に気にすることがなければこちらで問題ありません。

名前の由来はヨーロッパの十四行詩。バランスと表現力からこれをつけているらしいです。

 

Claude 3.5 Haiku

軽量で応答速度が早いのが特徴です。リアルタイムでの処理を検討するのに利用します。

名前の由来はご存じ日本の俳句。短い内容に多くの意味が込められているからでしょうか。

Claude 3 Opus

有料ですが、文章生成や複雑なタスク処理について特化したモデルです。

名前の由来はラテン語の「作品」で、最上級という意味があるとのこと。OperatorとかのOpe-の語源らしい(初めてしりました。)

 

参考

docs.anthropic.com

 

Gemini(Google

Googleが提供しているサービスで、Googleとのサービス連携に強みがあります。

また、検索性も優秀です。

 

Gemini 2.0 Flash

Geminiシリーズでもっとも汎用的なモデルです。

音声・画像・動画・テキストに対応しており、他サービスと異なり単体でこれらを同時に処理ができます。

 

Gemini 2.0 Flash-Lite

Geminiの軽量・高速版。他サービスと同じく、リアルタイムが求められるものに利用が適しています。

 

Gemini 2.0 Flash Thinkging

名前にThinkingとあるとおり、推論機能が通常よりも強化されています。

 

参考

ai.google.dev

 

Copilot(Microsoft/OpenAI)

MicrosoftがOpenAIの技術を活用して提供するAIアシスタントで、WindowsやOffice製品と統合されているのが最大の強みです。ほぼすべての会社で採用されているMicrosoft製品に最も導入しやすいと思ってます。

あれ、これAzureでも聞いたことある気が

 

モデルについて

これまでのと大きく異なることは独自のモデルというのを持たず、OpenAIのGPT-4を利用していることです。

OpneAIのモデルは先程紹介したので詳細は省きますが、金額によって連携先が異なります。

 

Copilot

無料で利用できる基本版。BingやEdgeに統合され、一般的な質問・検索・文章作成に対応。

Word、ExcelOutlook などのMicrosoft製品とも連携可能。

Copilot Pro

有料版で、高度なAI機能を利用可能。GPT-4oを搭載し、OfficeアプリでのAI支援が強化される。

特にExcelでのデータ分析やPowerPointのプレゼン作成を支援する機能が特徴。

 

参考

www.microsoft.com

 

おまけ:Grok(X)

他と比較して長文処理や要約といったところが優れています。長いコンテキストを保持することができるので、文脈理解力の部分が高いです。

 

どう使い分けるのがいいのか

あくまで自分の使い方になるので、参考までにというレベルです。CopilotはMacユーザなので未だに使い道を模索してます。仕事に使うのが良さそうなのですが、使用できないので頭かかえています。

 

なお以下の例は全部暴論です()

 

日常的な調べごと:特にこだわりなし(次の記事で紹介するAI検索のほうがよく使う)

リアルタイムでの調べごとは今回紹介したものではGeminiやGrok以外は難しく、別途使うほうが楽ですので。

一般的な質問ならどれでも大差ない(普通目線です)ので、どれでもいいかなって気がします。

仕事に必要な調べごと:GPT-4o

これは会社で用意しているのと、エンジニアはSTEM分野の強いほうが楽なので。Github Copilotとかがいいと言われたらあれですが、インフラはあまりコードを書かないので・・・。

同人誌を書くときの添削:Claude Opus

文章能力が優れているのと、PDFとかをそのままいれることで添削してもらえるのが楽でした。画像とか表紙みたいなものを削除したPDFを放り込むと案外気づかないミスも指摘してくれてました。頒布物はこちらにあります()

虹色旅録

Googleのサービスを使い倒すのに利用する:Gemini

Google連携するのに課金が必要ですが、メールの検索やドライブの検索もできるようになるので、一括で管理すると大変便利になります。企業さんとかでGoogle Workspaceを使っていればこれだけでも価値はありますね。

最新情報を取得:Grok

公式アカウントも情報を出しているので、聞いてみるとそこそこの精度で帰ってきます。いくつもの沼に浸かっているひとは今月申し込み締め切りの情報とかで調べるとよさそうでした。

 

簡単にまとめるつもりが

えげつない量になりました・・・。モデルの違いとかよくわからずに生きてきたので調べながら書くとものすごく時間かかりますね。

これどこまでシリーズ化してかくのか悩み始めてます。

 

トップ画像はGrokで対話っぽいコメントの画像を作成してもらいました。

JAWSDAYS2024の参加レポと資料まとめ

こんにちは/こんばんは、もつといいます。某会社のSREとしてインフラ,SaaS領域を使ってます。あ、JAWS-UG初心者支部運営やってます。

2024/3/2に行われたJAWS DAYS2024に参加してきたので、感想とかを書いていこうと思います。
※主に行ったことない人むけなのでライトな内容です。

jawsdays2024.jaws-ug.jp

 

 

全部聞く前提なら一般参加がおすすめ

コロナ禍前に行くことができず、今回初参加となったわけですが、とりあえずボランティアスタッフ枠として申し込みました。
どこのシフトに入るのかは決まってなかったので、事前受付が必要なセッションの参加はしませんでした(個人的にそんな余裕がなかったのですが。。。)

面白そうな場所はすぐに埋まってしまうのと、このイベント自体が割と早めに行ける枠が埋まってしまうので、見つけたら速攻で申し込みが必要です。

 

行けなかった人というのも何人か聞いていますので、いけるかいけないか考えずに申し込むといいです。

 

でもボランティアスタッフも捨てがたい

増えていくオリジナルTシャツ

このあとにボランティアスタッフの申し込みもスタートしていますが、僕はスタッフ参加を積極的に勧めています(当日登壇するのであればしなくていいかなと思います)

 

スタッフとして参加するメリットは強制的に誰かと話せることです。一人できて誰かと話そうにも話せなかったという人も多いと思いますが、シフトなどでかぶる人とは絶対に話せますし、懇親会でもスタッフTシャツを来ているので話しかけに行けやすいです。

 

記念撮影とかもありますし()

 

当日はリュックなどで行くべし

企業ブースが多いものありましたが、なんだかんだいいながらノベルティでいっぱいになります(ステッカーもかなりありましたが、AWSのみ載せてます)。聞きたかったあの企業や初めて知ったあの企業と1:1で話せますし、こういったコミュニティに参加している人は話すのがそれなりに好きな人なので、遠慮なく行くことができます。

 

ちなみに当日の椅子はパイプ椅子なのでE-JAWSご提供のクッション?もありました。使いたいけどもったいない()

 

懇親会は時間つくってでも参加しましょう

オフラインの魅力はオンラインでは作りきれないつながりを作ることだと思ってます。気楽に話しかけた人が実は・・・みたいな人もあるので積極的にどこかに凸するのがいいです。心理的にちょっとな・・という人もいると思いますが、ボランティアスタッフをやってると絡んだ人を見つけに行ってそこから広げるという手法も取ることができます。

そもそもここに参加している時点で面白い人と知り合いたいという人が多数なので、名刺交換やSNSのアカウント交換などしましょう。プレーリーカードとかもいいですよね。

prairie.cards

 

こういう雑多なところから発展する話はオフライン交流会ならではです。

 

今回のセッション資料一覧

自分が見れなかったもの、見返したいものもあるので、備忘録的にまとめてます。登壇者の方がまとめたものも載せているつもりですが、見落としてたら教えて下さい。

 

なぜAWS向けのFrameworkに携わり続けるのか?~クラウド時代のOSS活動~

speakerdeck.com

 

チーム対抗提案コンペ 〜仮想RFPに提案してみよう!

speakerdeck.com

 

CIer・SIer集まれ!!クライアントワークな私たちとAWSの良い関係を考えよう!

www.docswell.com

note.com

 

サービスクォータ、ちゃんと監視してますか?

speakerdeck.com

 

人材育成専門企業の内製開発の現場から

www.docswell.com

 

フルAWSのマルチテナントSaaS生成AIアプリ「かぐたん」開発秘話

www.docswell.com

 

AWS認定 Specialityレベルで満点取った時の勉強法

speakerdeck.com

 

地方在住フルリモートワークエンジニアのリアル〜ジモトで"活きる"エンジニアライフ〜

speakerdeck.com

 

次世代への種を蒔こう〜学生と社会人との交差点として、JAWS-UGができること〜

note.com

 

生成AIで社内文書検索!Bedrockの新機能でRAGアプリを簡単に作ってみよう

qiita.com

 

コネクタベンダーがAWSのゼロETL サービス、ぜんぶ触ってみた!

speakerdeck.com

 

クラウドネイティブなデータ連携の最新動向:AWSサービスアップデートで何が変わった?

speakerdeck.com

 

コンサルタントに聞く! AWS Security の守り方とセキュリティテストの実例

speakerdeck.com

 

サーバーレスで豊島区の緊急設備トラブルを解決するアプリを作った話

speakerdeck.com

 

AWS LLM 開発支援プログラム: 開発者から学ぶ、LLM開発の最前線

speakerdeck.com

 

海外イベントのためのコミュニケーションワークショップーPollyは友達ー

speakerdeck.com

 

技術書を書く技術:あなたの知識を世界に届けよう!!

togetter.com

 

予知保全はできるのか? Amazon Monitronによるガス火力発電所の機器監視

speakerdeck.com

 

恒例!ソリューションアーキテクト怒涛のLT

speakerdeck.com

 

来年もぜひ参加を

来年も同時期にやるので、1人でも多くの人が参加してほしいですね。