電通総研のブログ - TECH PLAY

TECH PLAY

電通総研

電通総研 の技術ブログ

851

はじめまして。 エンタープライズ 第二本部、1年目の藤城龍之介です。 本記事では、ITほぼ未経験の状態から 応用情報技術者試験 において入社半年で上位約0.1% に食い込んだ体験談と 10の戦略 を紹介します。 私が実際に行った学習方法や反省点も含めて、応用情報の戦い方を記しますのでぜひ参考にしていただければと思います。 なお、本記事では 応用情報技術者試験 を取り上げていますが、 その他の資格試験の対策に活用できるところもある かと思いますので、応用情報以外を受験する方もご一読いただければ幸いです。 目次 当時の私のスペックと状況 応用情報技術者試験の概要 勉強方法 スケージュールと勉強時間 使用した教材 インプット アウトプット(午前試験) アウトプット(午後試験) 試験直前 2日前 前日 試験本番 試験前 午前試験 昼休憩 午後試験 所感 結果 まとめ 10の戦略まとめ 最後に 当時の私のスペックと状況 ITほぼ未経験(電気系の理系大卒) 社会人1年目 IT系資格 保有 なし 理系科目は割と得意 暗記はかなり苦手 私が応用情報を受けようと思ったのは、ただ資格を取りたいというわけではなく、自社の研修とは別に自身でもIT系の知識をつけていきたいと思ったからです。 そこで、ITに関する体系的かつ使える知識を得られそうな応用情報を受験することにしました。(基本情報か応用情報が取得必須資格だったのもあるが...) 資格は取ることを目標にするのもいいですが、知識が体系的にまとめられており、効率よく知識を習得するのに最適だと考えています。 また、自身の知識を増やし、理解を深めることを目的に取り組むと気持ちも入りやすくなると思います。 応用情報技術者試験 の概要 応用情報技術者試験 は午前試験と午後試験があり、 どちらも60点以上 で合格です。 なお、午前試験で60点以上取らないと、午後試験は採点されないそうです。 午前試験 試験時間 9:30 ~ 12:00(150分) 出題形式 多肢選択式(四肢択一) 出題数 80問 午後試験 試験時間 13:00 ~ 15:30(150分) 出題形式 記述式 出題数 11問(解答は5問:1問必答、4問選択) 試験科目 1. セキュリティ(必答) 2. 経営戦略系 3. アルゴリズム 4. システム アーキテクチャ 5. ネットワーク 6. データベース 7. 組み込みシステム 8. システム開発 9. プロジェクトマネジメント 10. システムマネジメント 11. システム監査 勉強方法 それではここから勉強方法について紹介します。 スケジュールと勉強時間 入社と同時(4月)に勉強を開始しましたが、すぐにペースが落ちました。 結局7月末まではダラダラと勉強を続けていたため、この期間は平均するとおそらく1日あたり1時間くらい勉強していました。 8月になってさすがにマズいと思い、平日3時間、休日5時間くらいの勉強に切り替えました。 休日少なくない?と思った方もいると思いますが、趣味などに時間を使ったりして適度なリフレッシュをすることで勉強時間内にしっかりと集中することができました。 戦略①:適度なリフレッシュで勉強時間の効率を上げる → 特に休日は1:1くらいの割合でリフレッシュする というわけで、結局学習時間としては 約400時間 ほど取りました。 しかし、今思えば4~7月の勉強ではほとんど身に付いていない気がするので、実際には 約300時間 くらいだと思います。 もっと後から勉強開始して集中して取り組めていたら良かったと考えています。 戦略②:勉強開始は集中力を保てる期間を見据えてから → 応用情報は3, 4か月前がオススメ 使用した教材 使用した教材は3つで、以下で紹介する3つのフェーズごとに使い分けておりました。 書籍 令和06年【春期】【秋期】 応用情報技術者 合格教本 2024 応用情報技術者 午後問題の重点対策 Webサイト 応用情報技術者過去問道場 インプット(~ 9月中旬) インプットで使ったのは 合格教本 で、暗記が苦手な私は以下のようにインプットしました。 ちなみに、私はテク ノロ ジ系の知識が欲しかっただけなので、この教材のマネジメントとストラテジは飛ばしました。 → 後のアウトプットで何とかなりました ・1周目:理解できないところがなくなるようにノートに書きながら読む ⇒ 丸暗記ではなく、原理や考え方などを他の要素と結び付けながら理解することで暗記量をできるだけ減らしました。 ・2周目:自身が書いたノートを読み返して復習 → 理解できていないところは再度書きながらチェックする ⇒ 1周だけでは完璧に理解できないので、分かりづらいと感じたところはインターネットも併用しながらさらに理解を深めました。 ・3周目:さらにノートで復習 → 暗記するしかないところを覚える ⇒ とにかく丸暗記するという行為が嫌いなので、2周してできるだけ丸暗記の量を減らし、最後の最後で暗記するしかないところを覚えました。 このように、体系的に繋げて理解することを念頭に学習を進めることで、丸暗記の量を減らすことができる上、内容も十分に理解することもできました。 当初の目的であった、体系的かつ使えるITの知識を得ることができたと思います。 暗記が得意な方も、応用情報の範囲は莫大で丸暗記するにはかなりの根気がいると思いますので、ぜひ「繋げて理解する」ことを念頭に勉強していただければと思います。 戦略③:丸暗記をやめて体系的に「繋げて理解する」ことに専念する → 繋げて理解することで、使える知識へと昇華できる、かつ最終的に時短にもなる アウトプット(午前試験 / 9月下旬) インプットで9月中旬くらいまで使い、ここでやっとアウトプットに入りました。 まずは午前試験対策です。 9月末を使い、 過去問道場 で午前試験の過去問を3年分(6回分)、解きました。 ここで意識したことは以下の3点です。 1. 試験方式を確認し、慣れること 2. 知識の抜け漏れを補完し、インプットで得た知識を確認すること 3. マネジメントとストラテジ(インプットをしなかった科目)について知ること まず意識することは、試験で問題がどのような形式で出て、どのような時間配分で解けばいいのかを確認することです。 これは6回分もやれば十分につかめると思います。 次に、知識の抜け漏れを補完することです。( これが重要! ) インプットで入れたものは100%定着するわけではないので、ここでさらに思い出すことによって知識を補完・確認していきます。 また、試験では多少 合格教本 に書いていないことも出題されるので、そこについてはインプットフェーズのように新たに知識を入れていきます。 なお、マネジメントとストラテジについてはここで問題を解くことで十分に解けるようになりました。 * 欲しい知識には個人差があるので、おすすめしているわけではありません。 戦略④:アウトプットはあくまで試験の形式の確認と知識の補完・確認 → インプットで得た知識を確認すると共に抜け漏れをなくす 過去問はたくさん解いた方が良いとは思いますが、IT業界の知識は日々アップデートされていくのでそこまで古い過去問に手を出す必要はないと思います。 再度になりますが、実際にやってみて6回分も解けば十分だと思いました。 戦略⑤:過去問を解くのは適度に終わらせて良い → 6回分で十分 アウトプット(午後試験 / 10月上旬) 10月に入り、午後試験の対策を始めました。 午後試験は1回分が長く、自分で問題を厳選するのが面倒だったため、 午後問題の重点対策 を使って、どのような問題が出るのか掴むことにしました。 基本的には、解く問題をある程度先に絞ってからその分野だけ過去問を解いて慣れていくことがオススメです。 午後試験は4問が選択問題で、6問は解かない問題になるので、時間が十分にある方以外は選択する問題を絞って勉強するのが効果的だと思います。 私は以下のように午後問題を絞りました。 確実に解く問題は2, 3問決めておき、問題文を見て決める問題を1, 2問に絞っておくと学習も本番も余裕ができます。 あくまで私の特性(長文を読むことが苦手)とこれまでの学習方法に対する選定方法なので、自身の特性と学習状況に応じて選定してみてください。 〇:確実に解く問題 △:本番の問題文読んでから決める問題 ✕:絶対に解かない問題 △ → ✕:問題集を解いてみた結果、絶対解かないように変更した問題 科目 選択 説明・選定理由 1. セキュリティ 必須 午前の知識がある前提で、問題を読めば解ける 2. 戦略系 ✕ 文章が長く、知識も浅い 3. アルゴリズム 〇 変数の説明をしっかり読み、具体例や図を用いて明確化すれば解ける 4. システム アーキテクチャ △ → ✕ 計算問題が多く、ミスもしやすい傾向があった 5. ネットワーク △ 記述が難しいことがあるが、ある程度の得点源になる 6. データベース △ いかついER図などが出てきてタイパが悪い回がある 7. 組み込みシステム 〇 知っているモノが出ることが多く、事例が理解しやすい 8. システム開発 〇 事例を理解することに専念すれば、あとは自社の研修内容で解ける 9. プロジェクトマネジメント ✕ 文章が長く、知識も浅い 10. サービスマネジメント ✕ 文章が長く、知識も浅い 11. システム監査 △ → ✕ 文章が長い このように、事例の文章も長く、インプットをしなかったマネジメント、ストラテジ系以外の問題(6問)を解いて検証し、自分にあったものをスタメンとしました。 できるだけ絞ることで、勉強の効率が大幅に上がるのに加え、本番で問題を読んで迷って時間を食うこともないので、学習の段階から絞って勉強するのはかなりオススメです。 戦略⑥:午後問題は思い切って絞る → 確実に解く問題を2, 3問に絞り、重点的に学習する 試験直前 2日前 試験2日前は、アウトプットに使っていたノートを見ながら復習をしました。 どのような問題でミスしたかを再確認することで、もう一度記憶を整理し、定着させました。 前日 前日はインプットに使っていたノートで復習をしました。 学んだことを確認し、知識の結びつきを再度整理することで、本番に向けて準備を整えることができたと思います。 それ以外の時間は趣味に充て、頭を休めました。 戦略⑦:試験直前は復習するだけ → 直前に詰め込もうとしても焦りでインプットできないため、やったことを復習し、あとは自由に過ごす 試験当日 試験前 会場は行ったことがない駅の近くの専門学校でした。 朝早かったこともあり、集合時間の 1 時間前くらいに会場の最寄り駅まで行き、集合時間ギリギリまで近くの公園で朝ご飯を食べながらノートで最終確認をしていました。(教室は空気が重く不自由だったのでこの選択は正解だった…) ちなみに、持って行った教材は自分がインプットとアウトプットで使ったノート4冊です。 戦略⑧:試験日の朝は周りの空気に呑まれないように → 自分でその環境を作り出すことが大事 午前試験 午前試験では分からない問題はとにかく後回しにして、まず一通り解き終わることを目標にしました。 結局大幅に時間が余ったため、分からなかった問題も含めて 3 回くらい見直しをすることができました。 昼休憩の時間に 過去問道場 のサイトで解答速報が出るので、それに備えて問題に自分の解答を書き込んでおくことも大切です。 早く解き終わったら退出できるので、昼休憩を有効に使いたい人は退出するのもオススメです。 昼休憩 昼休憩時は、朝と同様の公園で昼ご飯を食べながら、解答速報を見て答え合わせをしました。 合格ラインに乗っていたので、心置きなく午後試験に臨むことができたと思います。 昼休憩は多少の復習もしましたが、公園で少し体を動かすことでかなりのリフレッシュになりました。 戦略⑨:昼休憩は頭を休める → 体を動かしたりして気分転換をする 午後試験 午後試験は立てた戦略通り、確実に解く問題である、以下の問題を先に解きました。 1. セキュリティ 3. アルゴリズム 7. 組み込みシステム 8. システム開発 しかし、この年は組み込みシステムがとても難しく感じ、ここだけは一旦問題用紙に解答を書き込んでネットワークとデータベースを解くことにしました。 問題文を読み始めると、想定よりもネットワークが簡単だったため、その後の解答にかなりの余裕ができ、ネットワークとデータベース、組み込みシステムを全て解いて比較することができました。 結果的には、想定よりも簡単だったネットワーク、少しでも点が取れる見込みのあった組み込みシステムを解答として提出しました。 所感 過去問をあまり多く解いていないこともあり、見たことのない問題が多かったですが、繋げて理解することにフォーカスして勉強した結果、当日も考えながら解答を導出できたと思います。 また、午後試験で多少の想定外のトラブルがありましたが、落ち着いて別の解答を進めることで最終的には時間に余裕ができたため、この方法を取ってよかったと思っています。 戦略⑩:試験時に分からない問題は後回し → 分かる問題から解き進めることで時間と心の余裕を確保する 結果 結果は… 無事合格できました! 午前が85点、午後が90点です。 得点分布をみると、午前は上位約3%、午後は上位約0.1%でした。 IT ほぼ未経験からここまで得点を上げることができたのも、理解に専念したからだと思っています。 特に午後は過去問が出ることはないので、どれだけ理解しているかがものを言うと思います。 そのため、午前よりも午後の方が得点が高い結果となったのだろうと思っています。 まとめ 10の戦略まとめ ここまでで紹介した10の戦略をまとめておきます。 人によって合う合わないがあるかと思いますが、参考にしていただければ幸いです。 ● スケジューリング 戦略①:適度なリフレッシュで勉強時間の効率を上げる → 特に休日は1:1くらいの割合でリフレッシュする 戦略②:勉強開始は集中力を保てる期間を見据えてから → 応用情報は3, 4か月前がオススメ ● 学習 戦略③:丸暗記をやめて体系的に「繋げて理解する」ことに専念する → 繋げて理解することで、使える知識へと昇華できる、かつ最終的に時短にもなる 戦略④:アウトプットはあくまで試験の形式の確認と知識の補完・確認 → インプットで得た知識を確認すると共に抜け漏れをなくす 戦略⑤:過去問を解くのは適度に終わらせて良い → 6回分で十分 戦略⑥:午後問題は思い切って絞る → 確実に解く問題を2, 3問に絞り、重点的に学習する ● 試験直前 戦略⑦:試験直前は復習するだけ → 直前に詰め込もうとしても焦りでインプットできないため、やったことを復習し、あとは自由に過ごす ● 試験当日 戦略⑧:試験日の朝は周りの空気に呑まれないように → 自分でその環境を作り出すことが大事 戦略⑨:昼休憩は頭を休める → 体を動かしたりして気分転換をする 戦略⑩:試験時に分からない問題は後回し → 分かる問題から解き進めることで時間と心の余裕を確保する 最後に ここまで読んでいただきありがとうございます。 応用情報はかなり出題範囲が広く、網羅するのは根気が必要ですが、「繋げて理解する」ことで効率的に学習を進めていきましょう。 あくまで私の学習方法と戦略ですが、今後応用情報を勉強する方の一助となれば幸いです! 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆: @fujishiro.ryunosuke 、レビュー: @handa.kenta ( Shodo で執筆されました ) table { width: 100% !important; border-collapse: collapse; } td { border: 1px solid #000; padding: 8px; word-wrap: break-word; } td:first-child { background-color: #d3d3d3; font-weight: bold; } blockquote { border-left: 5px solid #388e3c !important; background: #e8f5e9; padding: 10px; }
こんにちは。 エンタープライズ 第一本部の新人、佐藤悠です はじめに 質問しまくる新人の私 タスクは思考の過程から文字に起こす新人の私 RAGとは Bedrock knoeledgebasesでRAGを作成してみた 参考資料 はじめに 質問しまくる新人の私 私は現在、先輩社員の手を煩わせながら日々の業務を行っています。 先輩は質問を歓迎していますが、将来自分が同じ立場になった際に同じ振る舞いができる気がしないので今から対策をしようと思いつきました。 仕事で分からないことは当然のようですが2つに分けることができると思っています。 調べれば分かること 聞かないと分からないこと 当たり前ですが新人は聞かないと分からないことで質問をします。(私は調べればわかるが聞いた方が早そうなことは聞きますけど...) 業務上ではこのような聞かないと分からないような属人的な知識を扱うことがあります。 現場では、ほとんどが文書化されデータが存在しアクセス可能なところにありますが、規模が大きく複雑化した結果、その文書のありかを知っている人が限られているというような状態にも陥りがちです。 タスクは思考の過程から文字に起こす新人の私 私はあまりワーキングメモリがなく、次々と考えることが増えたときや次の日に持ち越した際に何をすればいいのか分からなくなりやすいので、以下のようにmdファイルでまとめたものがタスクごとに存在しています(実案件のものなので文字は読めないようぼかしてます)。 ここで割とこまめに文書に書き起こす自分の特徴とRAGって相性いいなと感じました。 前置きが長くなりましたが、この記事では業務上で扱う個別具体的な情報を回答できるように、自分がまとめたmdファイルでRAGを作成できるのかを技術的に検証します。 RAGとは 大規模 言語モデル 自体に変更を加えることなく参照する情報を指定することでハルシネーションの回避や特有の知識に対する回答の精度を高めることができます。 今回は以下のような構成を AWS 上で準備することを考えます。 LangChainでRAGを実装することもできますが普段使用している AWS でフルマネジドで作成することができるBedrock Knowledge bases[1]が簡単なので今回はこれを使用します。 Bedrock Knowledge basesでRAGを作成してみた 埋め込むデータは検証なので以下のようなダミーデータにしました。 これをRAGを使用せずに生成AIに案件Bの担当者は誰ですかと聞いても答えることは不可能でしょう。 では、先ほどのmdファイルをデータソースとして使用するためにS3に配置します。 次にBedrock Knowledge basesでこれを埋め込みするソースに指定します。 マネジメントコンソールでBedrockと検索し左のメニューからKnowledgebaseを選択します。 Knowledgebaseを作成を押下すると遷移先の画面でデータソースを指定できます。 次へを押下した遷移先で実際にmdファイルを置いた バケット の URI を指定します。 後は特別な設定をしない場合はアクセス許可をした埋め込み用のモデルを指定して、ベクトルデータベースをクイック作成で完了です。 ストア先は OpenSearch を使用しました。 作成したデータソースを同期します。 では無事に検索するべき情報をコンテキストに渡す準備ができました。 以下の指示にどのような回答が返ってくるかテストします。 いかに....!? 生成AIの思考では出せない一般的ではない名前のデータを出力させることに成功しました。 これで検証を終わります。 社内情報を使用していいのかとかの線引きを含めて超えないといけない壁は複数ありそうですが、技術的にできるのは嬉しいです。 ここまで読んでいただきありがとうございました。 参考資料 [1]How Amazon Bedrock knowledge bases work https://docs.aws.amazon.com/bedrock/latest/userguide/kb-how-it-works.html 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆: @sato.yu 、レビュー: @nagamatsu.yuji ( Shodo で執筆されました )
こんにちは、クロス イノベーション 本部エンジニアリングテク ノロ ジー センターの小澤英泰です。 本記事では GitHub Discussionsで ADR を管理する方法を紹介します。 はじめに ADRとは 筆者チームのGitHubとの関わり方 ADR導入の目的 ADRに備えたい性質 記載内容 運用 ADRの構成 全体構成 個別の説明 タイトル ステータス コンテキスト 決定 影響 コンプライアンス 参考情報 備考 ADRのステータス管理 ステータスの遷移図 個別のステータス Draft(ドラフト) Proposed(提案中) Review Rejected(却下) Accepted(承認済み) Deprecated(非推奨) Superseded(置き換え) 他のドキュメントとの違い ADRの管理にGitHub Discussionsを採用した理由 比較観点 比較検討 結果 Discussions リポジトリのdocsフォルダ Issues Wiki GitHub Discussionsでの運用で得たTips 無効なADRもOpenのままとする DiscussionとIssueに関連を持たせる アーキテクチャの決定をGitHub Copilotに読ませる さいごに ADRの例 ステータス コンテキスト 決定 結論 採用の選択肢とその理由 GitHub Packages(npm packages) 採用見送りの選択肢とその課題 GitHub Packages(Docker Images) Monorepo Micro Service 影響 コンプライアンス 参考情報 備考 はじめに ADR とは ADR とは Architecture Decision Record の略称で、定義は AWSのADRに関するドキュメント を拝借します。 An architectural decision record ( ADR ) is a document that describes a choice the team makes about a significant aspect of the software architecture they’re planning to build. Each ADR describes the architectural decision, its context, and its consequences. ADRs have states and therefore follow a lifecycle. ADR とは、チームが構築するソフトウェア アーキテクチャ の重要な選択を記述する文書です。 各 ADR には、 アーキテクチャ の決定、その背景、およびその結果を記述します。 ADR には状態とライフサイクルがあります。 Architecture Decision Recordをカタカナで アーキテクチャ ディシジョンレコード と表記する場面もありますが、手短に本ブログでは ADR で統一します。 定義だけでは想像が難しいと思いますので、ご参考までに 本記事の最下部にプロジェクトで管理するADR を記載しました。 筆者チームの GitHub との関わり方 本題に入る前に、筆者チームにおける GitHub の活用方法を紹介します。 私たちは普段5人前後の開発チームでプロダクト開発を行うことが多く、プロダクトオーナーもGit/ GitHub を積極的に活用します。構成管理以外にも下記のようにプロダクト開発で扱うツールを GitHub に集約し、連携することでメリットを最大限に引き出すことを目指しています。 GitHub Actions: CI/CD GitHub Codespaces: 開発環境 GitHub Discussions: 技術に関する議論や ADR 、議事録の管理 GitHub Issues: 課題管理 GitHub Packages: ソフトウェアパッケージの ホスティング GitHub Pages: Storybookや API 仕様書の ホスティング GitHub Projects: プロジェクト管理 ドキュメント管理においては、 GitHub を信頼できる唯一の情報源として位置づけ、他のツールとの分散を避けることで、情報の一元化と信頼性の向上を狙っています。 また、 アーキテクチャ の決定に影響のあるすべてのメンバーが GitHub にアクセスできることを前提とし、透明性を確保しながらプロダクト開発をしています。 ADR 導入の目的 それでは、本題に入っていきましょう。 ADR 導入の目的は 未来のプロジェクトメンバーが当時の アーキテクチャ 決定の トレードオフ まで理解できること です。 特定の課題により採用を見送った アーキテクチャ についても、経緯と判断理由を記録することで、将来のリ アーキテクチャ 時に同様の問題を見落とし、障害やリスクを引き起こすことの未然防止を目的としています。オーラルヒストリーで課題を引き継ぐのは困難を伴うでしょう。 ADR に備えたい性質 次に、上記目的を達成するための ADR に備えたい性質を 記載内容 と 運用 の観点で整理します。 記載内容 採用 アーキテクチャ と採用理由 採用を見送った アーキテクチャ と課題 関連する利用中の技術や業務、組織的な制約 ドキュメントの有効と無効を判別できるステータス 運用 簡潔なテンプレートがある 作成およびメンテナンスのコストが低い 継続的な運用フローがある すべてのプロジェクト関係者がアクセスできる 誰がいつ何を変更したかを追跡できる 他のドキュメントやコードと整合性が取れている 適切にレビューされ、承認されている ADR の構成 上記の目的や性質を踏まえ、 ADR の構成を下記としました。 全体構成 タイトル ステータス コンテキスト 決定 影響 コンプライアンス 参考情報 備考 個別の説明 タイトル アーキテクチャ 決定の簡単な説明 フォーマットは [ADR_番号] タイトル 例、 [ADR_002] 基盤コードの公開方法 ステータス ステータスは6種類あり Draft(ドラフト) Proposed(提案中) Accepted(承認済み) Rejected(却下) Deprecated(非推奨) Superseded(置き換え) ステータスの詳細は後述の ADR のステータス管理 を参照 コンテキスト 決定を下した状況 利用中の既存技術との兼ね合いや組織や体制、ビジネス面の時間的な制約を踏まえる 決定 決定と根拠 他の採用を見送った候補と課題 影響 決定による影響 コンプライアンス 決定が遵守されていることを確認する方法 参考情報 参照すべき一次情報 理解を促すブログ(任意) 備考 その他の備考(任意) ADR のステータス管理 ADR のステータス遷移と、レビューのプロセスを定義します。 Acceptedのステータスが唯一、 ADR が有効であることを示します。 ステータスの遷移図 個別のステータス Draft(ドラフト) 提案者が作成中の状態 他のメンバーへは周知前 Proposed(提案中) 周知済みでありレビュー可能な状態 Review ※ 判断でありステータスではありません。 レビュー完了の場合、承認または却下へ進む 指摘事項ありの場合、修正者へ差し戻す Rejected(却下) レビューを経て採用せず却下とした状態 ADR 作成者は却下の理由を ADR に追記する 決定が無効であることを示す Accepted(承認済み) レビューを経て承認した状態 決定が有効であることを示す Deprecated(非推奨) 承認済みの ADR を技術または業務、その他の理由により推奨しない状態 決定が無効であることを示す Superseded(置き換え) 既存の承認済みの ADR の内容を、更新または代替する新しい ADR を承認した状態 決定が無効であることを示す 承認済みの ADR を随時更新せず、新規 ADR を作成することに注意 他のドキュメントとの違い ADR と類似するドキュメントの 伝統的な アーキテクチャ 記述 や DesignDoc との違いを整理します。 伝統的な アーキテクチャ 記述(Traditional Software Architecture Description) とは、『 Design It! 』にて言及のある、権威的であり成果物に含まれる設計ドキュメントです。膨大で包括的な特徴があります。 DesignDoc とは、特定の機能の設計方針や技術選定をまとめ、開発チーム内での合意形成や意思決定に扱う設計ドキュメントです。 ADR と重複する部分もありますが機能や処理方式に焦点を当てています。DesignDocを作成する場合は、 アーキテクチャ 決定に関する部分を ADR に記載し参照とするのもよいでしょう。 伝統的な アーキテクチャ 記述 DesignDoc ADR 目的 システム全体の アーキテクチャ を記録 特定機能や設計変更の記録 特定 アーキテクチャ 上の決定を記録 スコープ システム全体 特定の機能や コンポーネント 特定の決定やその影響範囲に限定 記録内容 システム全体の構造、依存関係、非機能要件など包括的に記録 機能の設計詳細や技術的 トレードオフ 決定の背景、選択肢、結論、影響を記録 作成タイミング プロジェクトの初期段階から納品までの期間 機能開発前や開発中 機能変更が生じたタイミング 重要な アーキテクチャ 決定が行われたタイミング 利用期間 長期的(システムが稼働する限り) 長期的(機能がある限り) 長期的(決定が有効な間) 更新頻度 低 高 低(承認後の内容は更新せず新たに作成) 更新難易度 高 低 低 形式 権威的で公式 簡潔 簡潔 内容の粒度 詳細かつ包括的 実用的かつ軽量 実用的かつ軽量 主な読者 開発チーム、運用チーム、納品先 開発チーム 開発チーム ADR の管理に GitHub Discussionsを採用した理由 筆者チームのGitHubとの関わり方 のとおり、ツールは GitHub に集約する方針のため、ドキュメント管理も GitHub で運用する前提があります。 GitHub の中でもドキュメントを管理する方法は複数あり、下記4つの候補を検討しました。 Discussions リポジトリ のdocsフォルダ Issues Wiki 比較観点 ADR の GitHub での管理方法の4候補を下記5つの観点で比較します。 構成管理 誰がいつ何を変更したか追跡できるか テンプレートの利用 決まったフォーマットで新規作成できる、または複製できるか 検索性 タイトルや内容を特定ワードで検索できるか フィルターの容易性 他用途のドキュメントと分離できるか ADR の一覧化をできるか ADR にレビューを残せるか レビューコメントをどこに残すか 比較検討 結果 下表の比較結果より、 ADR 管理にはDiscussionsを採用しました。 Discussions リポジトリ のdocsフォルダ Issues Wiki 構成管理 ◎ ◎ ◎ ◎ テンプレートの利用 ◎ ◎ ◎ ◯ 検索性 ◎ ◎ ◎ ◯ フィルターの容易性 ◎ ◯ ◯ ◯ ADR にレビューを残せるか ◎ ◯ ◯ × ◎: 容易に可能 ○: 可能 ×: 不可能または現実的でない Discussions 構成管理(◎) 右上のeditedのプルダウンから追跡可能 ステータス管理の方法から通常のコードと比較して、変更数は少ないため十分と判断 テンプレートの利用(◎) Discussion Templateでテンプレート化可能 .github/DISCUSSION_TEMPLATE/{categoryName}.yaml のようにカテゴリ名の YAML を作成。Issue Templateと異なり YAML のファイル名に規則あり。詳細は公式ページを参照 ディスカッション カテゴリ フォームの作成 検索性(◎) テキスト検索が可能 フィルターの容易性(◎) サイドバーの ADR のカテゴリー選択によるフィルター(1クリック) ラベルでのフィルターも可能 ADR ラベルと ADR のステータスのラベル、関連技術のラベル付与により視認性向上 ADR にレビューを残せるか(◎) Discussion内でのコメントとしてレビュー テーマごとにスレッド化して、スレッド内でリプライ可能 ADR 本体とレビューのコメントが同一ページにあり、思考過程を辿ることができる リポジトリ のdocsフォルダ 構成管理(◎) 明らか テンプレートの利用(◎) テンプレートファイルを用意し、複製利用 検索性(◎) テキスト検索が可能 フィルターの容易性(◯) /docs/ adr 配下に集約することで他のドキュメントと分離 /docs/ adr 配下にフラットに配置するか、 ADR の種類に応じて ディレクト リを切るかは検討の余地ありのため評価は◯ ADR にレビューを残せるか(◯) PRにてレビュー。 ADR から該当のPRを探す手間ありのため評価は◯ GitHub 上からファイルをBlameビューで表示してPRを辿る Issues 構成管理(◎) 右上のEditsのプルダウンから追跡可能 テンプレートの利用(◎) Issue Templateでテンプレート化可能 .github/ISSUE_TEMPLATE/{templateName}.yml でテンプレート化 検索性(◎) テキスト検索が可能 フィルターの容易性(◯) Labelsのプルダウンから ADR ラベルでフィルター(2クリック) Discussionは1クリックのため評価は◯ ADR にレビューを残せるか(◯) スレッド化はできないがフラットにコメント可能なため評価は◯ Wiki 構成管理(◎) revisionsから追跡可能 テンプレートの利用(◯) テンプレートのページを作成し、複製利用 ファイルの複製と比較すると手間があるため評価は◯ 検索性(◯) Wiki 単体に検索機能はないが、 リポジトリ 全体で検索可能なため評価は◯ フィルターの容易性(◯) サイドバーで階層構造を表現できるが手間があるため評価は◯ ADR にレビューを残せるか(×) ADR に追記することでレビューとコメントが可能だが現実的でないため評価は× GitHub Discussionsでの運用で得たTips GitHub Discussionsを用いて、 ADR 管理をシンプルに運用することができます。運用する中で得たTipsを紹介します。 無効な ADR もOpenのままとする ADR のステータスがDeprecated、Rejected、Supersededに変化し、無効な ADR となってもDiscussionはOpenのままで運用します。これは GitHub Discussionsのデフォルトのフィルター条件がOpenなDiscussionのみ表示のためです。無効な ADR 含め一覧で見たいため、無効な ADR もCloseしません。 DiscussionとIssueに関連を持たせる Discssionに記述した ADR がIssueの課題に関連を持つ場合は辿れるように相互にリンクを貼ります。 Discussionsページの検索窓からはIssueは検索範囲外です。Issueやコードを含めて検索したい場合は、 リポジトリ 全体で検索しましょう。 アーキテクチャ の決定を GitHub Copilotに読ませる 2025年3月時点では、 GitHub Copilotは GitHub Discussionsのドキュメントを読み取ることはできないようです。 アーキテクチャ の決定を GitHub Copilotに読ませたい場合は、必要な箇所を リポジトリ のdocsやREADME、copilot-instructions.mdに記載しましょう。 さいごに ADR の目的から構成やステータスを定め、 GitHub Discussionsを用いて ADR を管理する方法を紹介しました。今後の運用で新たな気づきがあれば、改めて記事を投稿したいと思います。 プロジェクトによって ADR の最適な管理方法は異なりますが、1つの例として参考になれば幸いです。 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 キャリア採用サイト 電通総研 新卒採用サイト ADR の例 タイトル: [ ADR _002] 基盤コードの公開方法 ステータス Proposed コンテキスト 案件カスタマイズをする際に基盤のコードを利用し、容易に案件カスタマイズを実施できるようにしたい。 基盤のコードをどのようにパッケージングし、公開するかを検討する。 決定 結論 以下の候補を検討し、 GitHub Packages(npm packages)として公開することとする。 GitHub Packages npm packages Docker Images Monorepo Micro Service 評価の観点は以下。 独立性 基盤コードと案件コードが独立しているか 利用容易性 案件側から容易にパッケージを利用できるか パッケージのインターフェースは便利か カスタマイズ性 案件側で振る舞いを変更できるか 案件側で振る舞いを上書きできるか 拡張性 基盤コードはメンテナンスしやすいか 基盤コードは機能追加しやすいか 方法 独立性 利用容易性 カスタマイズ性 拡張性 GitHub Packages(npm packages) ◯ △ ◯ ◯ GitHub Packages(Docker Images) ◯ △ × △ Monorepo × ◯ ◯ × Micro Service ◯ × ◯ ◯ 採用の選択肢とその理由 GitHub Packages(npm packages) 独立性(◯) - 基盤コードと案件コードで リポジトリ を分割可能 パッケージはバージョニングできるため、基盤コードのバージョン間でも独立している 利用容易性(△) ユーザはnpm installで利用可能 実装にもよるがライブラリ形式のためある程度の利便性 コンポーネント の組み合わせ相当の実装は呼び出し側の責務となり、多少実装コストがある カスタマイズ性(◯) 引数やpropsによって振りまいを変更可能 利用しにくい コンポーネント は独自 コンポーネント で差し替えることが可能 メンテナンス・拡張性(◯) 新しい コンポーネント を追加したり、 コンポーネント のpropsを増やしたりし、機能追加が可能 採用見送りの選択肢とその課題 GitHub Packages(Docker Images) 独立性(◯) リポジトリ を分割できる バージョニングできる 利用容易性(△) Docker Image形式で利用可能 呼び出し側はDocker実行時のパラメータを変更するのみ パラメータが大量になる可能性あり カスタマイズ性(×) パラメータを変更することで振る舞いを変更可能 振る舞いの上書きはできない パラメータ以上の振る舞い変更は不可能 拡張性(△) 実行時パラメータを増やすことで拡張可能 カスタマイズの数だけ実行時パラメータが増えてしまう 引数が大量にあるDocker Imagesは基盤側にとっても案件側にとっても便利ではないと予想 Monorepo 独立性(×) ディレクト リ相当のため、独立性があるかと言われると微妙 案件担当者が基盤コードを直接参照したり、修正できたりする バージョニングできない 利用容易性(◯) npm workspaceなどを使ったライブラリの形式になる ライブラリ形式のため GitHub Packages(npm packages)と同程度か コードのコピペも可能 カスタマイズ性(◯) パラメータを変更することで振る舞いを変更可能 パラメータ以上の振る舞い変更は不可能 メンテナンス・拡張性(×) - バージョニングができないため、基盤コードの修正とリリースが簡単に実施できない Micro Service 独立性(◯) リポジトリ の分割ができる バージョニングができる 利用容易性(×) API を通した呼び出しになる バックエンド機能の共有には便利だが、フロントエンドコードの共有は難しい カスタマイズ性(◯) API のパラメータを変更することで振る舞いを変更可能 API を利用せず、独自実装を用いることで振る舞いを上書き可能 メンテナンス・拡張性(◯) API を拡張していく方式になる 影響 GitHub リポジトリ を新しく作り、その リポジトリ でパッケージング用のビルド スクリプト を書き、 GitHub PackagesにpushするCIフローを書く 公開の際のバージョニングの方法を別途検討する コンプライアンス 基盤コードの リポジトリ を分割し、その リポジトリ からパッケージを公開することで、 GitHub Pacakges(npm packages)経由での利用を案件側に強制することが可能。 基盤コードの リポジトリ についてはアクセス制限を厳密に実施する。 外部メンバーにはwrite, read程度の権限を付与し、mainブランチはブランチプロテクションで制限し、自分たちの知らないところで基盤コードを変更されないようにする。 基盤コードを案件開発者が閲覧し、案件コードにコピペすることは許容する。 参考情報 https://tech.dentsusoken.com/entry/2025/02/25/_%E8%A3%BD%E5%93%81%E3%81%AE%E3%82%A2%E3%83%89%E3%82%AA%E3%83%B3%E3%82%92%E5%AE%9F%E7%8F%BE%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E6%9C%80%E9%81%A9%E3%81%AA%E3%82%A2%E3%83%97%E3%83%AD%E3%83%BC 備考 別途案件カスタマイズ時の初期セットアップをサポートするために、Template リポジトリ を作りたい 執筆: @ozawa.hideyasu 、レビュー: @takami.yusuke ( Shodo で執筆されました )
はいどーもー! エンタープライズ 第一本部の宮澤響です! 本記事では、私が運営チームリーダーとして運営を主導した弊社の社内イベントである「AHEAD AWARD 2024」についてご紹介します! (イベントの詳細には社外秘の情報も含まれますが、当然そのような内容は記載できないため、全体的にあっさりめの表現となっています…ご容赦ください…!) (こんなイベントがあるんだな、こんな組織風土なんだな、というようなことを感じ取っていただけたら幸いです…!) (その意味では、弊社について情報収集している就活生やキャリア入社検討中の方向けの記事かなと思います…!) AHEAD AWARDとは? どんなことをするの? 運営チームリーダーをやってみての感想など おわりに AHEAD AWARDとは? AHEAD AWARDとは、「弊社の 行動指針 である『AHEAD』を体現し、弊社や弊社のお客様への貢献度の高い活動を、社員投票によって選定する、社員による社員のためのアワード」とされています。 噛み砕いていえば、2024年に実施されたあらゆる活動の中から自薦形式でノミネートを募り、プレゼンテーションや全社投票を経て受賞活動を決定・表彰するイベントです。 そのため、2025年開催ではあるものの、イベント名はAHEAD AWARD 2024 となります。 なお、他社様においては、フューチャー株式会社の「Best Project of the Year」などが近しいイベントかなと思います。 どんなことをするの? AHEAD AWARD 2024の大まかな流れは以下でした。 (内容は年々アップデートされていきますので、こちらはあくまで今回の内容です!) エントリー AHEAD AWARD 2024にエントリーする活動を、活動代表者の方からの自薦形式で募集します。 対象となる活動は上述のとおり2024年に実施されたあらゆる活動であり、対外的な有償案件だけでなく、自社内の施策や取り組みなども含まれます。 応募にあたっては、活動代表者の方にPRシートと呼ばれる資料を提出していただきます。 PRシートには、活動の概要やアピールポイントなどを記載していただきます。 ノミネート活動選定 運営チームなどが中心となって、エントリーされた活動の中からノミネート活動を選定します。 ノミネート活動に選定された活動は、これ以降の投票やプレゼンテーションに駒を進められます。 事前投票 ノミネート活動のPRシートやPR動画を公開し、全社投票を実施します。 社員のみなさまには、「AHEAD」を体現していると感じる活動に投票してもらいます。 プレゼンテーション ノミネート活動の代表者や関係者がプレゼンテーションを実施します。 プレゼンテーションはオンラインでも配信されるため、現地/オンラインを問わず視聴できます。 当日投票 プレゼンテーションを踏まえた上で、改めて全社投票を実施します。 PRシートやPR動画だけでは分からなかった長所や魅力が反映された投票となります。 表彰 事前投票と当日投票の票数を合算して、受賞活動を決定します。 AHEAD AWARD 2024では、Gold Prize、Silver Prize、Bronze Prizeの3つの賞がありました。 それぞれの賞を受賞した活動に対しては、トロフィーや副賞が贈呈されます。 後夜祭 最後は後夜祭と称した立食形式のミニパー ティー を開催します。 こちらはノミネート活動関係者に限らずどなたでも参加可能です。 弊社の社内同好会である 電通 総研Jazz部のみなさまによる生演奏も行われました。 運営チームリーダーをやってみての感想など まず第一に、運営チームメンバーやノミネート活動関係者のみなさまとの本部・事業部の枠を越えた繋がりができたことが大きな財産になったと感じています。 いわゆる通常の業務ではどうしても同じ部署のメンバーや同じ案件に携わっているメンバーとしか関わりがない状態になりがちなのですが、今回の活動を通して社内の垣根を越えた繋がりを構築できました。 また、弊社の活動を知る良い機会にもなったと感じています。 普段から他部署がどんなことをやっているのかを把握できているわけではなかったため、PRシートやプレゼンテーションなどを通じて他部署の活動内容を知ることができ、弊社全体の業務に対する理解が深まりました。 なお、現在はAHEAD AWARD 2025の運営メンバーに向けた引き継ぎ資料を作成中です。 というのも、AHEAD AWARDの運営チームは、リーダーやサブリーダーは前年の運営メンバーから選出されるものの、基本的にメンバーが毎年入れ替わります。 そのため、ただ開催して終わりというわけではなく、その後の振り返りや引き継ぎが重要となります。 このあたりも最後まできっちりこなしていく所存です。 おわりに 本記事では、弊社の社内イベントであるAHEAD AWARD 2024についてご紹介しました! 本業の傍ら、このようなイベント運営にも手を挙げられるような働き方に興味がある、という方は、チラ見だけでも結構ですので、弊社の 新卒採用サイト や キャリア採用サイト をご覧いただければと思います。 最後までお読みいただき、本当にありがとうございました! 私たちは共に働いていただける仲間を募集しています! みなさまのご応募、お待ちしています! 株式会社電通総研 新卒採用サイト 株式会社電通総研 キャリア採用サイト 執筆: @miyazawa.hibiki 、レビュー: @iwasaka.emari ( Shodo で執筆されました )
注意: 2025年2月現在、WhiskおよびImageFXの商用利用について、 Google は公式な規約を発表していません。 本記事は個人的な検証を行うものであり、現時点では実際のビジネスでの利用は想定しておりません。 生成された画像については私的利用の範囲内に限定します。また、本記事には画像生成AIによって作成されたイラストが多く含まれます。 二次利用 はお控えください。また、本記事で紹介した手法により発生したいかなるトラブルについても弊社は一切の責任を負いません。あらかじめご了承ください。 こんにちは。 エンタープライズ 第一本部 戦略ソリューション 1 部の英です。 普段はWebアプリや スマホ アプリの案件などを担当しています。あと、趣味でAIを勉強しています。 最近登場したWhiskが面白そうなので触ってみます。 Whisk は2025年2月12日から試運転が始まったばかりの新しいサービスです。 1:Whiskについて 2:前置き 3:今回の検証内容について 4:検証 補足:モデルを作るときのプロンプトサンプル さいごに 1:Whiskについて まず、Whiskは Google が提供するこんなサービスです。 詳細についてはコチラの リンク をご参照ください。 冒頭でお伝えした通り、 著作権 や利用範囲に関する明確な記述がないのが現状です。 そのため、本記事を参考としたビジネスシーンでの利用につきましては、利用するご本人様の責任でお願いいたします。 弊社は一切の責任を負いませんので、あらかじめご了承ください。 Whiskでは、スタイルと背景を指定し、その範囲内でモデルを描くことができます。 これまでの画像生成AIではプロンプトを用いて 自然言語 でスタイルや背景を細かく指示していました。 自然言語 でそれらを完璧に表現することが難しく、同じプロンプトでも生成するたびに絵柄が変わってしまうというのがあるあるでした。 今回のWhiskではその「絵柄」を画像ファイルから指定できるようになったと捉えていただければと思います。 この機能を使えば、同じ「絵柄」の画像を量産できるのではないか? そんな野望が芽生えたので、会社のテックブログで消化します。 2:前置き 今回は画像生成AIを取り扱うため、前置きが長めです。お付き合いください。 さて、世の中に画像生成AIが登場して からし ばらく経ちました。 これまで 著作権 についてたくさんの議論が起こっては消滅し、また新たな火種が投下されては論争が起こる。 そんな日々がもう何年も続いています。 個人的な考えですが、日本国内に限定した話ならば、国が定める ガイドライン が絶対的なルールです。これは各自で調べてください。その次に参照すべきは各生成AIツールが定める規約だと思います。 ビジネスマンとして、最低限これらのルールは遵守して利用しなければなりません。 とはいえ、ルールの中でカバーしきれていない倫理的な問題を抱えているのも事実で、これらが「感情論」の一言で片づけられている今の世の中にも問題があるとは思います。個人的なクリエイターの目線でもそう思います。 新しい技術には否定的な意見が付き物です。様々な声を聴きながら技術は少しずつ進歩します。 もしかしたら10年後には新しいルールが策定され、この記事で書いてあることがすべて違法なんてことにもなるかもしれません。その時はその時です。その時になったら、その時の最新のルールの中で最適な判断を下しましょう。 ここはドライに考えないと、価値の創造が止まってしまいます。 3:今回の検証内容について 皆さんはプレゼン資料に差し込む画像素材ってどこで調達しているでしょうか。 商用フリーの素材サイトもあれば、買い切りの素材サイトなど色々ありますよね。 今回はWhiskを活用して、欲しい素材を自分で作る実験をしてみます。 もう一度言います。実験です。 前述の通り、Whiskでは「絵柄」の指定ができます。 有名な素材サイトだと「いらすとや」という素晴らしいサービスがありますが、イラストの絵柄が特徴的ですよね。 この絵柄を継承した「AIいらすとや」というサービスがあります。 では、その「AIいらすとや」が生成した画像の 著作権 についてはどうか。 これはサービスの規約にこのように明記されています。 ※引用: AIいらすとや これも当然かと思います。 なぜならばプロンプトを書くのはサービスの利用者であり、プロンプトに基づいて新しい画像が生成されます。 プロンプトという自由入力に対して、サービス側が責任を持つことはあまりにも荷が重すぎます。 例を挙げるとするなら、AIいらすとやを開いて、ピ〇チュウとでも入力してみてください。 危ない。ほんとに危ない。 周りの可愛いやつらはまだよいですが、モザイクをかけた部分なんてほぼピ〇チュウです。 人間が描いた絵も、AIが描いた絵も、アウトプットが既存の著作物に類似しているかという観点が重要です。 私が手書きで ピカチュウ のイラストを描いて1枚100円で売ったら明らかに 著作権侵害 ですし、AIで ピカチュウ のイラストを描いて1枚100円で売っても 著作権侵害 です。手法が違うだけで犯している問題は同じ。 もし、このような問題に対してサービス側が責任を負うならば、 絶対に安全な画像しか生成されない定型文 を何度も検証し、ユーザーはその定型文から選択するだけみたいなUI/UXに縛らないといけません。 そんな仕様では、t2iのサービスとしては破綻してしまいます。誰も使わず寂れていくだけでしょう。 だからこそ使い方には制限をかけず、生成された成果物に対する責任の考え方について規約で明確にしているのだと察します。 ちなみに、Sunoのような音楽生成のサービスでも同じようなルールが採用されています。自己責任だということです。 ※引用: Suno さて、ではWhiskはどうでしょうか。 Whiskにはこのように記載があります。 規約のリンク先では 生成してはいけないもののリスト が公開されています。そして、生成におけるコン トロール の主体はユーザーだと言っています。つまり、生成されたものが著作物に似すぎたり、グロすぎたり、性的だったりしたらユーザーが責任をもってプロンプトで指示内容を調整しないといけません。 例えば、Whiskのスタイルに 鳥山明 先生のイラスト、背景にディズニー映画、モデルにピ〇チュウの画像を指定して画像を生成したとしましょう。これを商用利用してしまった日には大炎上確定です。 確定演出で画面が虹色に輝いて、スピーカーからキュインキュイン音が鳴るでしょう。ついでにクビになります。 ※ほんとに見せられません 4:検証 今回はできるだけ安全に使いたいので、手書きのイラストをベースにします。 私が5分で描きました。このイラストの 著作権 は私にあります。 ビジネス向けのイラストってだいたいこんな顔してますよね。 これをスタイルに差し込んで、背景は無地を指定します。 プロンプトをいじりながらいくつか画像を生成してみましょう。 1.サッカーをしている少年 ※モデルはプロンプトにより生成(A simple, monochrome, single-line flat illustration of a young boy playing soccer. He has short, slightly messy hair and is wearing a sports jersey and shorts. He is kicking a soccer ball with one foot, with motion lines around the ball to emphasize movement. His expression is focused and energetic. The illustration is minimalistic, using clean, continuous black lines on a white background, without shading or extra details.) 2.何かをひらめいたビジネスマン ※モデルはプロンプトにより生成(A simple, monochrome, single-line flat illustration of a young boy playing soccer. He has short, slightly messy hair and is wearing a sports jersey and shorts. He is kicking a soccer ball with one foot, with motion lines around the ball to emphasize movement. His expression is focused and energetic. The illustration is minimalistic, using clean, continuous black lines on a white background, without shading or extra details.) 3.ランチを食べている女性 ※私の絵と似ていないものはモザイクをかけています ※モデルはプロンプトにより生成(A simple, monochrome, single-line flat illustration of a woman eating lunch. She has shoulder-length hair and is wearing a casual outfit or business attire. She holds a lunch box, sandwich, or bowl in one hand and a utensil in the other. Her expression is relaxed and content. The illustration is minimalistic, using clean, continuous black lines on a white background, without shading or extra details.) 4.運転をしている男性 ※私の絵と似ていないものはモザイクをかけています ※モデルはプロンプトにより生成(A simple, monochrome, single-line flat illustration of a man driving a car. He has short hair and is wearing a casual shirt or suit. He grips the steering wheel with both hands, looking forward with a neutral or focused expression. The illustration is minimalistic, using clean, continuous black lines on a white background, without shading or extra details.) 5.プレゼンをしている男性 ※モデルはプロンプトにより生成(A simple, monochrome, single-line flat illustration of a man giving a presentation. He has short hair and is wearing a suit with a tie. He is standing confidently, gesturing with one hand while holding a pointer or remote control in the other. A simple presentation board or screen with minimal bar charts or graphs is in the background. The illustration is minimalistic, using clean, continuous black lines on a white background, without shading or extra details.) 補足:モデルを作るときのプロンプトサンプル 目的 プロンプト 効果 白黒の線画にする black and white line art, high contrast, pen and ink style, no grayscale グレーの階調を徹底的に排除し、ペン画風のメリハリある線画を得やすくなる。 一本の線で描くようにする single continuous line drawing, one-line art, minimal detail 一本の流れるような線で描いたシンプルなイラストを生成しやすくなる。 フラットなデザイン flat vector-style illustration, minimal shading, no gradients 奥行きや立体感を抑え、 ベクター アートのようなフラットな仕上がりを得やすくなる。 描き込みを減らす ultra-minimalist design, reduce extraneous details, simple lines 余計な装飾を削ぎ落とし、シンプルで視認性の高いイラストを得やすくなる。 さいごに けっこう期待していたのですが、全体的に「なんとなく絵柄が似ているかもな」くらいの印象です。 これは私の手書きイラストのクオリティが低かったことが原因だと思います。 画力に自信のある人は手元の環境でぜひ試してみてください。 まだ実験段階とはいえ、無料でこのクオリティのサービスを提供する Google には頭が上がりませんね。 これを悪用して素材サイトで販売しようかな?とか思わない方がよいです。 今後、画像生成AIに関する世の中の考えかたや法律がどのように変わっていくか静観しましょう。 これからも AWS やAI関連の検証記事をたくさん書いていきます。 ↓ のスターを押していただけると嬉しいです。励みになります。 最後まで読んでいただき、ありがとうございました。 エンタープライズ 第一本部では一緒に働いてくださる仲間を募集中です。以下のリンクからお願いします。 私たちは一緒に働いてくれる仲間を募集しています! 中途採用-エンタープライズ第一本部 新卒採用-エンタープライズ第一本部 執筆: 英 良治 (@hanabusa.ryoji) 、レビュー: @nakamura.toshihiro ( Shodo で執筆されました )
こんにちは。 エンタープライズ 第一本部の新人、佐藤悠です。 はじめに 筆者について AIFの概要 AIFで問われるAWSサービス Amazon SageMaker [2] Amazon SageMaker Clarify [3] Amazon SageMaker Canvas [4] Amazon Bedrock [5] Amazon Bedrock ガードレール [6] その他のサービス AIFで問われる概念 責任あるAI [7] 機械学習の手法 LLMに関して 学習教材 CloudLicense Hands on for Beginers Amazon Bedrock Overview まとめ 参考にしたサイト はじめに 表題の通り AWS Certificated AI Practitioner(以下:AIF)に合格しました。 AIFは最近できた試験で問題集や調べて出てくる情報も少ないため概要や問われたサービス群、おすすめの学習方法を記します。 筆者について 学部は文系で情報を一切やっていない 大学院ではAIに関して研究 AWS 触り始めて半年 AIFの概要 AIFとは AWS 認定の公式ページ[1]によると以下のような知識を問う資格です。 AWS Certified AI Practitioner は、 人工知能 (AI)、 機械学習 (ML)、生成 AI の概念と ユースケース に関する需要の高い知識を実証します。 AIを活用する際にどのような手法を用いるべきかということが主に問われます。AIの活用はLLMが登場してから、さらに活発に行われてきた背景があり、この資格自体も最近できた比較的新しいものになります。 AIFで問われる AWS サービス 試験で問われる主な AWS サービスを紹介します。 Amazon SageMaker [2] 広く採用されている AWS の 機械学習 と分析機能をまとめた Amazon SageMaker は、分析と AI のための統合エクス ペリエ ンスを、すべてのデータに対する統合アクセスとともに提供します Amazon SageMaker Clarify [3] モデルの評価とモデル予測の説明 Amazon SageMaker Canvas [4] ビジュアル インターフェイス を使用して非常に正確な ML モデルを構築します Amazon Bedrock [5] 基盤モデルを使用して生成 AI アプリケーションを構築およびスケーリングする最も簡単な方法 LLMの文脈で問われた際にはこのサービスがほぼ必ず問われます。 頻繁に問われる内容としてはLLMの出力調整はプロンプトで行う点であったり、温度(Temparature)が回答のランダム性を生み出したりする点などがあげられます。 また、課金は基本的に トーク ンという言語をAIで扱う際の基本単位で決まるため入力や出力できる文字数の制限もでき、こちらも問われました。 トップPは確率的にとりうる選択肢を絞ります。 トップKは選択肢を上から指定した数だけ絞ります。 これらは生成される文章の多様性に影響します。 Amazon Bedrock ガードレール [6] Amazon Bedrock ガードレールには、生成 AI アプリケーションを大規模に安全に構築するのに役立つ設定可能な保護手段が用意されています これに関して例を挙げると子ども向けのLLMを構築する際に不適切な内容を表示しないようにするには?というような ユースケース でこのサービスを活用する方法が問われました。 その他のサービス 機械学習 (ML)と生成AI(LLM)の文脈で設問が設定されている時には以上のサービスに加えて OCR の Amazon Textractや感情分析の Amazon Comprehendなどが問われていました。これはAIの文脈以外でも頻繁に耳にするサービスではあるのでCloud Practitionerを取得した人ならば理解できる範囲の内容だとは思います。 この他にはAIそのものではないですが、生成AIエンドポイントにアクセスしたログの取得にCloud Trail,データの保存にS3,データの読み出しができない場合のポリシーの設定などもAI関連のソリューション提供の際に考えられる課題の一種で出題されました。 AIFで問われる概念 次にサービスとは異なる観点で出題される内容です。 責任あるAI [7] 公平さ 説明可能性 プライバシーとセキュリティ 制御性 正確性と堅牢性 ガバナンス 透明性 特に公平さと透明性に関して問われることが多かったです。 機械学習 の手法 線形回帰 ロジスティック回帰 サポートベクターマシン 決定木 ニューラルネットワーク 敵対的生成ネットワーク(GAN) k-means これは AWS のサービスには関係なく 機械学習 を使用する例においてどの手法を使用するべきかということを選択する形式の問題が出題されました。 どのような分析に使用され、どのような結果を出すかをセットでわかっていれば良いというレベルで数学的な観点は問われないので過度な心配は不要です。各手法について軽く調べてみてください。 LLMに関して トーク ン 埋めこみ プロンプトエンジニアリング RAG 近年、流行りのLLMに関する背景知識と応用の手法を問われます。 トーク ンや埋め込みLLMの基礎に関してはTransformerが登場した論文、(Attention Is All You Need)とBERTの論文、(BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding)などを読むと分かります。 有名な論文なので解説記事は山ほどあります。是非そちらも参考にしてみてください。 プロンプトエンジニアリングに関しては、期待する質問と回答のセットを渡すと回答の精度が向上する手法few-shotなどが出題されました。LLMを用いてどうやったら期待した回答を生成させれるか試してみると遊びながら勉強になるので良いと思います。 学習教材 CloudLicense https://cloud-license.com/ 他の資格に比べて学習できる問題数は少ないのでAIFのためだけに有料プランに加入するのはややもったいない感じもしますが、他の資格をすでにこちらで勉強していた人にはおすすめです。私はこれを一周し間違った問題のみを二周しました。 Hands on for Beginers https://pages.awscloud.com/JAPAN-event-OE-Hands-on-for-Beginners-AIML-2022-reg-event.html?trk=aws_introduction_page 初学者向けのハンズオンです。AI/MLに関するリソースを実際に作成し操作することで理解が深まります。 Amazon Bedrock Overview https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2024_Amazon-Bedrock-Overview_v1.pdf 分かりやすくBedrockの概要をつかむことができます。ここで マッピング した知識をもとに公式ドキュメントを読みに行くと、さらに理解が深まります。 まとめ AWS リソースだけでなくAIに関する基本的な概念を理解できる良い試験でした。 今後も必須になってくるAIと クラウド にこの試験から入門してみませんか? 受験を控えている人は参考になれば幸いです。 参考にしたサイト [1] https://aws.amazon.com/jp/certification/certified-ai-practitioner/ [2] https://aws.amazon.com/jp/sagemaker/ [3] https://aws.amazon.com/jp/sagemaker-ai/clarify/ [5] https://aws.amazon.com/jp/bedrock/ [6] https://aws.amazon.com/jp/bedrock/guardrails/ [7] https://aws.amazon.com/jp/ai/responsible-ai/ 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 新卒採用サイト 執筆: @sato.yu 、レビュー: @nagamatsu.yuji ( Shodo で執筆されました )
こんにちは、グループ経営ソリューション事業部でエンジニアをしている大浦です。 今回は、製品開発と切っても切れないアドオンの実現方法と、その選択がもたらす影響についてお話します。 製品におけるアドオン アドオンは本当に必要か? アドオンの実現方法 方法1. 製品のコードベースを直接編集する(モディフィケーション) 特徴 モディフィケーションの例 補足 考察 方法2. アドオンしたい機能のコードをコピーして別機能として作成する(コピーカスタマイズ) 特徴 コピーカスタマイズの例 考察 方法3. アプリケーションを拡張可能にし、実装を追加する(プラグイン) 特徴 プラグインの例 元コードへの拡張ポイント作成 拡張ポイントとして追加されたApproverProviderFactoryの実装 考察 アドオン方式選定まとめ 製品におけるアドオン アドオンとは、製品の標準機能を補完・拡張する追加要素です。 特定の顧客にとって重要だが標準機能では実現出来ない要件を実現する場合に選択肢となります。 アドオンは本当に必要か? いきなり結論を覆すように聞こえるかもしれませんが、まず強調したいのは、 「製品にアドオンすることが本当に最善の解決策かを十分に検討することの重要性」 です。 アドオンがもたらす影響として以下のようなものがあります。 複雑性の増加: アドオンを追加することで製品のコードベースは複雑になり、メンテナンスが困難になります。 サポートの負荷増: 顧客ごとのカスタマイズは、サポートチームにとっても大きな負担となります。 ドキュメントの不足: アドオンは製品標準の機能に比べてドキュメントが不十分になりがちです。 バグの特定が困難: 問題が発生した際に、製品固有の問題なのかアドオンの問題なのか判別が必要であり、切り分けが難しくなります。 できる限り、製品標準の機能で顧客の課題を解決できないかを模索しましょう。 もし顧客固有の要望を、適切に抽象化し標準機能として取り込めれば、製品の価値向上が期待でき、顧客にも喜ばれます。 しかし、現実には製品標準だけでは顧客の重要な課題を解決できない場合もあります。 製品開発において標準機能で実現する可能性は考えつくしたけれど、様々な理由で無理だと分かった場合に、どのようにアドオンを実現すべきかを考えてみましょう。 アドオンの実現方法 アドオンの実現方法は色々考えられます。 製品のコードベースを直接編集する(モディフィケーション) アドオンしたい機能のコードをコピーして別機能として作成する(コピーカスタマイズ) アプリケーションを拡張可能にし、実装を追加する( プラグイン ) etc(マイクロサービス化、イベント駆動による拡張、 API 連携、...) 私はアドオンの実現方法はソフトウェア アーキテクチャ の一部だと考えています。 書籍「ソフトウェア アーキテクチャ の基礎」には、以下の原則が書かれています。 ソフトウェア アーキテクチャ は トレードオフ が全て 「どうやって」よりも「なぜ」の方がずっと重要 (引用: ソフトウェアアーキテクチャの基礎 ) アドオンの実現方法も、どの方法が良いかはコンテキストに依存します。 製品のアドオン実装担当になった場合には、自身の置かれているコンテキストを考慮して判断することが必要です。 以下でそれぞれの方法の特徴を見ていきます。 方法1. 製品のコードベースを直接編集する(モディフィケーション) 1つ目は、製品のコードベースに直接必要な変更を行うモディフィケーションです。 特徴 Pros: 開発が迅速に行うことができ、あらゆる変更が可能 (○短期的な開発効率, パフォーマンス) Cons: コードベースが複雑化し、顧客数やバージョンが増えるごとに管理が困難 (×保守性, 拡張性) モディフィケーションの例 例えば、経費精算申請の例を考えてみます。(架空のコードです)。 以下のような Java コードで申請処理が実現されているとします。 public KeihiService { public void apply(KeihiRequest request) { // 申請内容の確認 checkRequest(request); // 合計金額の計算 calculateTotal(request); // 申請承認者の設定 setApprover(request); // 申請実施 submitRequest(request); } } ここで、今回アドオン要望としてA社から来た「申請者自身がマネージャの時は承認者を役員にする」という機能をモディフィケーションで実現します。 public KeihiService { public void apply(KeihiRequest request) { // 申請内容の確認 checkRequest(request); // 合計金額の計算 calculateTotal(request); // 承認者の設定 // A社アドオン: 申請者自身がマネージャの時は承認者を役員にする String applicantRole = request.getApplicant().getRole(); if ( "Manager" .equals(applicantRole)) { setExectiveApprover(request); } else { setApprover(request); } // 申請実施 submitRequest(request); } } 少しコードからいやな臭いがしてきましたが、実装自体はサクッと終わります。 次に、B社から続けて「プロジェクトを指定した場合は、承認者をプロジェクト管理者にする」という要望が来たとします。 A社に続きB社の要件もモディフィケーションで対応してみます。 public KeihiService { public void apply(ExpenseRequest request, Project project) { // 申請内容の確認 checkRequest(request); // 合計金額の計算 calculateTotal(request); // 承認者の設定 // A社アドオン: 申請者自身がマネージャの時は承認者を役員にする String applicantRole = request.getApplicant().getRole(); if ( "Manager" .equals(applicantRole)) { setExectiveApprover(request); // B社アドオン: プロジェクトを指定した場合は、承認者をプロジェクト管理者にする } else if (project != null ) { setProjectOwnerApprover(request, project); } else { setApprover(request); } // 申請実施 submitRequest(request); } } B社アドオンの実装者が実装しようとした際、コードには既に「A社アドオン」が実装されています。 実装者はそれを壊さないように実装しなければなりません。 補足 今回お話したい内容と少しずれてしまいますが、上記コードには気になる点があります。 B社の環境においてA社のアドオンの機能が動いてしまうかもしれない。 → これがB社にとって意図しない振る舞いとして現れた場合、顧客からの問合せとして顕在化します。 applyの引数にB社のアドオンでしか利用しないprojectが追加されている。 → B社のアドオン実装のみにフォーカスして実装するとこのような変更をしてしまうことがあります。この変更が妥当かは十分な議論が必要です。 実装者もレビューアも、上記のような観点を持つ必要があります。 Feature Toggle(機能の切り替え機構)や、条件分岐の整理のためにStrategyパターンの適用を検討すると意図しない副作用を減らせる可能性があります。 考察 モディフィケーションでの実現は短期的には効果的ですが、長期的には技術的負債を増やすリスクがあります。 新機能の追加やバージョンアップ時に大きな障害となる可能性が高いです。 方法2. アドオンしたい機能のコードをコピーして別機能として作成する(コピーカスタマイズ) 2つ目は、アドオンしたい機能のコードを顧客ごとに全てコピーし、別機能として作るコピーカスタマイズです。 特徴 Pros: 製品標準のコードは維持される、他の顧客向けに影響が出にくくなる (〇独立性, パフォーマンス) Cons: 冗長性が増し、差分管理しなければならないコードが多くなる(×保守性, 拡張性) コピーカスタマイズの例 モディフィケーションの例と同じ要件がA社、B社からそれぞれ来た場合にコピーカスタマイズで実現する場合を考えます。 A社アドオン「申請者自身がマネージャの時は承認者を役員にする」 public KeihiServiceForCompanyA { public void apply(KeihiRequest request) { // 申請内容の確認 checkRequest(request); // 合計金額の計算 calculateTotal(request); // 承認者の設定 // A社アドオン: 申請者自身がマネージャの時は承認者を役員にする String applicantRole = request.getApplicant().getRole(); if ( "Manager" .equals(applicantRole)) { setExectiveApprover(request); } else { setApprover(request); } // 申請実施 submitRequest(request); } } B社:「プロジェクトを指定した場合は、承認者をプロジェクト管理者にする」 public KeihiServiceForCompanyB { public void apply(ExpenseRequest request, Project project) { // 申請内容の確認 checkRequest(request); // 合計金額の計算 calculateTotal(request); // 承認者の設定 // B社アドオン: プロジェクトを指定した場合は、承認者をプロジェクト管理者にする if (project != null ) { setProjectOwnerApprover(request, project); } else { setApprover(request); } // 申請実施 submitRequest(request); } } モディフィケーションとの違いは、KeihiServiceクラスをコピーし、それぞれA社向け経費精算申請(KeihiServiceForCompanyA), B社向け経費精算申請(KeihiServiceForCompanyB)というクラスを作成してそれぞれ実装している所になります。 これにより、モディフィケーションの時に不安になった、「B社で動作する際のA社アドオンの影響」を軽減することが出来ます。 考察 複数社のアドオン実装が同一コードに入り乱れる複雑さは防げますが、管理するコードベースの量は増えます。これはモディフィケーションとは違ったコードベース管理の煩雑さ(例えば、Gitのブランチ運用やCI/CDパイプラインでの対処など)が発生します。 方法3. アプリケーションを拡張可能にし、実装を追加する( プラグイン ) 3つ目は、拡張ポイントを製品側に作り、その実装を追加することで実現する プラグイン です。 特徴 Pros: 必要な部分だけを拡張でき、アドオン機能を持続的に維持しやすい (○保守性, 拡張性, 再利用性) Cons: 拡張ポイントの設計が難しく、開発初期のコストが高くなります。(×開発効率, 複雑性, パフォーマンス) プラグイン の例 ここではあらかじめ「承認者の設定ロジックには顧客毎に違った要件が出る可能性が高い」ということが見えている前提でお話します。(このような観点はビジネスサイドが持っていることが多いです。) 元コードへの拡張ポイント作成 以下のように、元のコードにおける申請承認者の設定処理を、ApproverProviderFactoryというクラスを利用することで、実際の処理をApproverProviderに委譲します。 (注: 今回のコードでは、 Java で広く使われている Spring Framework の依存性注入を利用しています。) @Service public KeihiService { @Autowired private ApproverProviderFactory approverProviderFactory; public void apply(KeihiRequest request) { // 申請内容の確認 checkRequest(request); // 合計金額の計算 calculateTotal(request); // 申請承認者の設定(拡張可能な実装) approverProviderFactory.get().setApprover(request); // 申請実施 submitRequest(request); } } 拡張ポイントとして追加されたApproverProviderFactoryの実装 元コードに埋め込んだApproverProviderFactoryの実装です。 少し複雑ですが、get()では以下のルールの通り、ApproverProviderインターフェースの実装クラスの数を見て、適切なApproverProviderの実装クラスを返却しています。 ApproverProviderの実装クラスが1つの場合には、デフォルトの実装(DefaultApproverProvider)を返却します。 ApproverProviderの実装クラスが2つの場合には、デフォルト でない 実装を返却します。 @Component public class ApproverProviderFactory { @Autowired private ApplicationContext applicationContext; public ApproverProvider get() { // ApproverProvider インターフェースを実装している全ての Bean を取得 Map<String, ApproverProvider> beans = applicationContext.getBeansOfType(ApproverProvider. class ); int count = beans.size(); if (count == 1 ) { // 実装が1つしかなければ、アドオンは無いのでDefaultApproverProviderを使う return applicationContext.getBean(DefaultApproverProvider. class ); } if (count == 2 ) { // 実装が2つあれば、アドオン実装があるとみなし、DefaultApproverProviderでない実装を使う for (ApproverProvider provider : beans.values()) { if (!(provider instanceof DefaultApproverProvider)) { return provider; } } } throw new IllegalStateException( "Unexpected number of ApproverProvider implementations: " + count); } } 製品標準の機能としては、ApproverProvider実装としてDefaultApproverProviderクラスを実装しておきます。もし振る舞いを変えたい場合は、期待するアドオンの動作を別のApproverProviderの実装クラスとして定義します。ApproverProvierのアドオン実装が存在する場合には、実装クラスが2つになるため、アドオンした実装クラスが使われます。 こうすることで、元のコードに変更を加えることなく振る舞いの変更を実現できます。 今までの例で言えば、A社向け、B社向けそれぞれの振る舞いをするApproverProviderの実装クラスを作成します。それらの実装クラスを製品とは別のjar(以下、アドオンjar)として切り出し、製品コードの起動時に顧客に対応するアドオンjarを読み込むことで、製品コードに手を入れることなく、最小限の差分のみを管理することでアドオンを実現することができます。(=SOLID原則の1つであるオープン・クローズド原則に従い、新たな機能追加を既存コードの変更なしに実現できる点が大きなメリットです。) 考察 プラグイン は、設計と実装には高度な技術が必要ですが、その分将来的な拡張性と保守性が向上します。一方、上手く プラグイン 化出来たとしても、その箇所に変更があまり入らない場合は、余計な複雑さを埋め込んでしまいます。 アドオン方式選定まとめ 得られる特性 (〇) 失われる特性 (×) モディフィケーション 短期的な開発効率, パフォーマンス 保守性, 拡張性 コピーカスタマイズ 独立性, パフォーマンス 保守性, 拡張性 プラグイン 保守性, 拡張性, 再利用性 開発効率, 複雑性, パフォーマンス ここまで、3つのアドオン実現手法を紹介しました。 繰り返しになりますが、どの方法が良いかはコンテキストに依存します。 今回はモディフィケーションだと辛くなり、 プラグイン が有効となりそうなコードを例として書きました。ですが例えば「実現したいアドオン機能は後ほど製品の標準機能に取り込む可能性が高い」ということが分かっている場合は、迅速に実現できるモディフィケーションを選択することが妥当となるケースは十分に考えられます。 また「顧客ごとの完全なカスタマイズが求められ、他の顧客への影響を避けたいケース」であれば、コピーカスタマイズが最も良い選択肢となるかもしれません。 ここに挙げていない方式が妥当であることもあり、様々なメンバーと議論しながら妥当なものを選ぶことが重要です。 エンタープライズ アプリケーションの製品開発はビジネスサイドまで含めたコンテキストを加味した判断の連続です。 これからも、 トレードオフ を意識して議論し判断しながら、今後も製品開発を推進していきたいと考えています。 最後までお読みいただき、ありがとうございます。 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆: @oura.osamu 、レビュー: @nakamura.toshihiro ( Shodo で執筆されました )
はじめに クロス イノベーション 本部 クラウド イノベーション センター新卒2年目の宮崎です。 先日、 AWS のre:Inventに参加させていただきました。 個人的にハンズオンやGameDayに参加し、手を動かすことで スキルアップ しようと思い参加しましたので、参加して面白かったワークショップについてご紹介します。 re:Inventとは 下記記事に記載しております、ご興味がある方はご覧ください。 AWS re:Invent 2024とAWS GameDayについて ワークショップとは ワークショップは、約2時間程度のハンズオン型セッションです。各自のPCを使って新機能やサービスに実際に触れながら学べる場となっています。短時間で実践的にスキルを習得できるため、普段触れない技術に初めて挑戦する絶好の機会でもあります。 AWS re:Inventでは、新しいサービスを活用したワークショップが多く開催されていました。 一方で、JP Contents Hubというものに、多くのハンズオン・ワークショップがまとめられており、非常に便利です。 既存のサービスについて、机上の知識だけでなく実際に触れて動かしてみたい方には特におすすめのコンテンツになっていますので、ご興味がある方は手を動かしてみてください。 JP Contents Hub 英語ワークショップ情報 今回紹介するワークショップ 題名:SUP303 | Amazon Q を使用して運用および セキュリティインシデント の再発を防ぐ 内容(翻訳) AWS サポートケース、 AWS Trusted Advisor の推奨事項、 AWS Health 通知などの AWS 運用データを使用して、 Amazon Q Business の機能を見るもの。 冒頭で述べた各データを Amazon Q Business に取り込むことで、複雑なデータモデルを理解しなくても、 自然言語 での会話、根本原因の解明を行うことが可能になる。 AI アシスタント( Amazon Q Business)は、基礎となるデータソースへの直接リンクに裏打ちされたコンテキストに応じた回答を提供し、必要に応じてさらに調査できるようにする。 このワークショップでは、環境からのデータの収集、 Amazon Q Business アプリケーションの作成、データのインデックス作成、IT サービス管理 (ITSM) システム (ServiceNow、Jira、Zendesk など) との統合についても説明があった。 これにより、独自のプレイブック/ナレッジベースを使用してコンテキストに応じた推奨事項を受け取り、それらの推奨事項を実行して、パフォーマンスと信頼性に優れた AWS 環境を実現できるという内容。 前提知識 AWS には、サポートケースや Trusted Advisor、 AWS Health など、様々なデータが存在します。 これらを活用しようとしても、データがアカウントごとに散在していたり、適切な分析手段がなかったりすると、なかなか思うように可視化・活用できません。 そこで登場するのが、QSI (Support Insights with Amazon Q) です。 Amazon Q Business の生成 AI 機能を活用することで、選択したアカウント全体のサポートケース、Trusted Adviso、Healthデータから洞察や推奨事項を得て、可視化や情報の活用につなげることができるソリューションです。 QSI (Support Insights with Amazon Q) ※実態はCloud Formationで AWS リソースが作成できるテンプレートが含まれているものです、詳細は アーキテクチャ 図の部分で解説します。) QSI (Support Insights with Amazon Q) の詳細 参考: https://github.com/aws-samples/support-insights-with-amazon-q?tab=readme-ov-file 実際の アーキテクチャ 図は下記です。 ハンズオンではこの仕組みづくりを行いました。 Amazon Q Business を活用して AWS サポートデータを分析する仕組み 図からわかるQSIの構成要素 各アカウントの役割 ○DataCollection Account側(上部) スコープ内すべてのアカウントから、S3へそれぞれの情報を格納する中央集権アカウント。 ○Linked Account DataCollectionアカウント以外のアカウントで、 AWS サポートデータ( AWS サポートケース、Trusted Advisor、Health)を持っているアカウント。 参考情報 AWS Support AWS Trusted Advisor AWS Health 機能構成 ■ Amazon Q Business コンポーネント ユーザーがチャット形式でデータにアクセスし、 自然言語 で対話的に洞察を得られる環境。 Amazon Q Business アプリケーションと Web エクス ペリエ ンス モジュールが含まれている。 参考リンク ○ Amazon Q Web インターフェース チャットボットが稼働するウェブ画面。ユーザーはブラウザ上で “英語 or 日本語” (現時点では日本語対応無し)などの 自然言語 で質問し、リアルタイムに回答や推奨事項を得ることができる。 ○ Q Business Application Q Web インターフェースの背後にあるコアのアプリケーション。データソースや生成 AI エンジンとの連携を担っている。 ■ AWS Support Collectorモジュール 組織内の各 AWS アカウント(Linked Account)から、サポートケース/Trusted Advisor/ AWS Health といったデータを定期的に収集し、中央アカウント(Data Collection Account)の S3 バケット へアップロードする仕組みのモジュールです。 参考リンク ○ AWS Lambda & EventBridge リンクされたアカウントから定期的に各情報を取得するためのもの。 Lambda 関数と EventBridge (Scheduler) を組み合わせてスケジューリングして実行している。 ○ S3 バケット それぞれのデータソース(サポートケース、Trusted Advisor、Health)から収集した JSON 形式のサポートデータは、中央の Data Collection Account にある S3 バケット へアップロード。そこから Q アプリケーションが読み取り、インデックス化してチャットボットの応答に活用していく。 ハンズオンではQSI を構成する大きく これらの部分をデプロイしました。 ハンズオンを始める前の前提条件 ハンズオンを開始する前に、以下の前提条件があり下記の内容を実施しました。 IAM Identity Center の有効化の確認 SAML 2.0 に対応した IdP(Identity Provider)として IAM Identity Center が設定されている必要があります。また、少なくとも1人以上のユーザー(有効なメールアドレス)がプロビジョニングされている必要があります。 詳細については下記を参照してください。 https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html Amazon Q Business の対応リージョンの確認 Amazon Q Business を使用する場合は、対応するリージョンで操作を行う必要があります。 対応リージョンの一覧は下記を参照してください。 注意:日本(東京リージョン)は現時点では対応リージョンに含まれていません。 Amazon Qを触ってみたい方は、日本リージョン以外の対応リージョンを選択して操作を進めてください。 対応リージョンの一覧: https://docs.aws.amazon.com/amazonq/latest/qbusiness-ug/quotas-regions.html IAM Identity Center で多要素認証(MFA)の有効化 IAM Identity Center の多要素認証(MFA)はデフォルトで無効化されています。そのため設定を行い有効化します。 アイデンティティ ストアへのユーザー作成 IAM Identity Center インスタンス 内で少なくとも1人のユーザーが必要です。そのため、 アイデンティティ ストアにユーザーを作成します。 Q Business アプリケーションへのユーザー割り当て 前手順で作成したユーザーを Q Business アプリケーションに割り当てる必要があります。これを行わない場合、 Amazon Q Web エクス ペリエ ンスにアクセスしようとした際に「アクセスが拒否されました」というメッセージが表示されます。 S3 バケット の準備 管理アカウント(または Data Collection Account)に、 AWS サポートデータを格納するための S3 バケット を作成しておきます。 ※実際のAmazonQへログイン後の画面 ・IAM アイデンティティ センターで作成したユーザをQアプリに割り当てることで、そのユーザー情報でQアプリにアクセスすることができました。 デプロイ手順 CloudFormation テンプレートを入手 GitHub から以下のファイルをダウンロードします: https://github.com/aws-samples/support-insights-with-amazon-q/blob/main/src/q_application/amazon-q-cfn.yaml CloudFormation スタックの作成 https://console.aws.amazon.com/cloudformation/home を開き、リージョンを Amazon Q Business 対応リージョン に設定します。 「スタックの作成」 → 「新しいリソースを使用」 を選択し、ダウンロードした amazon -q-cfn. yaml をアップロード。 スタックの名前を例として amazon -q-cfn とし、以下のパラメータを入力 ①IAMIdentityCenterARN: IAM Identity Center インスタンス の ARN (IAM Identity Center コンソール → [設定に移動] → ARN コピー) ②QBusinessApplicationName: Q アプリケーション名 (任意) ③S3DataSourceBucket: サポートデータを置く S3 バケット 名 (例: qsi-app-data-ACCOUNT_ID) 最終画面で IAM ロール作成に同意し、スタックを作成。 スタックのステータスが CREATE_COMPLETE になるまで待機(約10分)。 ここで作成されたリソース 構成図の部分で前述した各リソースが作成されました。 Amazon Q Business コンポーネント AWS Support Collectorモジュール S3データソースコネクタ Web エクス ペリエ ンス (チャットインターフェース) インデックスユニット(初期は20,000件までのドキュメントを登録可能) データソースの同期 本テンプレートで作成したデータソース(サポートケース、Trusted Advisor、Health)は、毎日 UTC 深夜に S3 バケット 内のデータを同期するようにスケジューリングされています。 バケット 内にサポートデータ(あるいは合成データの zip 解凍結果)を配置すると、下記の手順で即時同期も可能です。 Amazon Q コンソール を開き、先ほど作成した Q アプリケーション名 を選択。 「データソース」のメニューから、S3データソースを手動で同期 (Sync) できます。 同期が完了すると、サポートデータがインデックス化され、Q Business 上で検索対象となる。 ユーザーのアクセス設定 Identity Center 上で Q Business へのアクセスが許可されたユーザー(またはグループ)を追加しておく。 CloudFormation の展開時に指定した IAM Identity Center ARN と連携されているため、Q Business 側から Identity Center のユーザー/グループを簡単に検索・割り当て可能。 Amazon Q Businessへのアクセス ここまで完了すると、 Amazon Q Business のWeb エクス ペリエ ンス(チャット画面)にアクセスできるようになりました。 手順 AWS マネジメントコンソール → Amazon Q Business → Q アプリケーション → Web エクス ペリエ ンスURL を開く。 Identity Center の認証画面でメールアドレス・パスワードなどを入力。 ログイン後、チャット画面が表示されるので質問が可能になります。 質問に対して Q Business が回答し、サポートケースの詳細や Trusted Advisorの推奨事項など、実際のサポートデータをもとにした洞察が返されます。 実際に質問してみた 試しに直近のイベントについて聞いてみました。 直近のHealthイベントに何があるかを聞く質問をすると、下記画像にあるように実際のイベントソースに基づいて回答を出力してくれました。 得られた回答の翻訳 データソースに基づき、最近報告されたヘルスイベントが2つあります: AWS MediaPackageに運用上の問題が発生し、ライブおよびオンデマンドコンテンツのビデオ再生が断続的に中断され、遅延が増加し、バッファリング時間が長くなっています。この問題は部分的に解決しており、24時間以内に完全に回復する見込みです。 また、2024年9月26日から29日にかけてWorkDocs API に問題が発生し、 API 操作に影響が出ましたが、WorkDocsサービス全体の可用性や既存のドキュメントのセキュリティには影響しませんでした。この期間中も、ユーザーはウェブ・ インターフェイス やデスクトップ・アプリケーションを通じてコンテンツにアクセスすることができました。 さらに、サポート・ケースによると、us-west-2リージョンにおけるRDSのバックアップに継続的な問題があり、自動バックアップが指定されたバックアップ・ウィンドウ内で完了せず、手動スナップショットが「バックアップ・ジョブ・キュー」ステータスで立ち往生しているとのことです。サポートチームは、これらのバックアップの失敗を積極的に調査し、影響を受ける顧客に トラブルシューティング の手順を提供しています。 優先順位が高く、対応が必要な5つの項目についても聞いてみました。 翻訳:データソースに基づき、取り組むべき優先事項のトップ5は以下のとおりである: セキュリティとアクセス制御: セキュリティ・グループ・ルールとネットワーク・アクセス・コン トロール ・リスト(NACL)を見直し、強化し、必要なインバウンド・ トラフィック のみを許可するようにする。 システムのアップデートと監視: インスタンス が最新のオペレーティング・システム・アップデートとセキュリティ・パッチを実行していることを確認し、包括的なセキュリティ・ロギングと監視を有効にして、 潜在的 な脅威を プロアクティブ に検出して対応する。 バックアップとストレージの管理: ストレージの割り当てを確認し、自動バックアップが正常に完了するのに十分な空き領域を確保することで、RDSのバックアップの失敗に対処します。 ヘルスチェックの実装: アプリケーションの健全性を正確に反映する適切な健全性チェックを構成し、イン フラリ ク エス トの完了と不健全な インスタンス の削除のバランスをとるために適切な登録解除遅延を設定する。 高可用性と耐障害性: インスタンス のマルチ アベイラビリティ ゾーン ディストリビューション を実装し、不健康な インスタンス を自動的に置き換えるためにオートスケーリングを利用し、可用性とパフォーマンスを向上させるために AWS Global Acceleratorの実装を検討する。 個人的に他にも下記のような質問ができると思いました。 「過去3か月で一番多かったサポートケースの内容は?」 「Trusted Advisor のコスト最適化に関する推奨事項を一覧で教えて」 「頻繁に発生している AWS Healthイベントの原因は?」 まとめ QSI (Support Insights with Amazon Q) は、 AWS サポートデータ(サポートケース、Trusted Advisor、Health)を特定のアカウントへ集約し、生成 AI と 会話型インターフェースによって高度な分析と推奨事項を得られるソリューションです。 実際のハンズオンでは、この仕組みの中核となる Amazon Q Business アプリケーション と AWS Support Collectorモジュールをデプロイし、ユーザーがチャットで簡単にサポート情報へアクセスできる環境を構築しました。 過去のサポートケースから発生しがちなインシデント傾向を素早く把握すること。 Trusted Advisor のリソース最適化情報をもとにコスト削減や信頼性向上など AWS の推奨に従った取り組みを検討する。 AWS Health のステータスを踏まえ、サービスイベントに プロアクティブ に対応していく。 上記のこれらを 1 つの対話型インターフェース で実現できるメリットは非常に大きいと思います。 クラウド 運用の効率化のために、ぜひ今後QSI を導入してみてはいかがでしょうか。 ※日本のリージョンではこれから対応されていくと思います。 また、今回ワークショップで使用した Amazon Qのアップデートには他にも様々あり、今後の日本語対応にも期待できる生成AIソリューションであるため、皆様もぜひ触ってみてください。 Amazon Q関連情報 Amazon Q Amazon Q Developer とは? Amazon Qを深めるハンズオン(このワークショップでもおすすめされていました) https://catalog.workshops.aws/amazon-q-business/en-US 私たちは一緒に働いてくれる仲間を募集しています! 株式会社 電通総研 新卒採用サイト 執筆: @miyazaki.hirotoshi 、レビュー: @miyazawa.hibiki ( Shodo で執筆されました )
こんにちは。クロス イノベーション 本部 クラウド イノベーション センターの柴田です。 ここ数年、生成 AI サービスが非常に注目を集めていますね。 電通 総研でも Know Narrator シリーズや minnect AI アシスト などのソリューションを提供しています。 さて。私はプロンプトを書くとき、まず Visual Studio Code で書いてから、それをブラウザの生成 AI サービスにコピー&ペーストしています。慣れ親しんだエディタの方が文章(プロンプト)を書きやすいからです。しかしあるときこう思いました。 「エディタからブラウザへプロンプトをコピー&ペーストするのが面倒だな🤔」「 Visual Studio Code から直接生成 AI サービスを呼び出せないかな🤔」 と。 そこで Visual Studio Code から生成 AI サービスを直接呼びだす方法を考えてみました。本記事ではその方法を紹介します。なお生成 AI サービスには Amazon Bedrock を使用します。 ※この記事では Visual Studio Code から AWS CLI を使って Amazon Bedrock の Converse API を呼びだす方法をご紹介します。 特定の 拡張機能 ( Cline など)を使った Visual Studio Code と生成 AI サービスの高度な連携については扱いません。 ご承知おきください。 必要なもの 前提条件 設定方法 実行方法 解説 おわりに 必要なもの Visual Studio Code AWS CLI 前提条件 以下は事前に完了しているものとします。 AWSCLI のセットアップ Amazon Bedrock の基盤モデルへのアクセス許可の設定 設定方法はそれぞれのユーザーガイドをご参照ください。 Configuring settings for the AWS CLI - AWS Command Line Interface Add or remove access to Amazon Bedrock foundation models - Amazon Bedrock 設定方法 Visual Studio Code から Amazon Bedrock を呼びだすための設定をします。 Visual Studio Code を起動します。 コマンドパレットを開きます。 Tasks: Open User Tasks と入力します。すると tasks.json が開きます。 tasks.json に以下の内容を入力して保存します。 { " version ": " 2.0.0 ", " tasks ": [ { " label ": " bedrock ", " type ": " shell ", " command ": " aws ", " args ": [ " bedrock-runtime ", " converse ", " --model-id ", " anthropic.claude-3-5-sonnet-20240620-v1:0 ", " --messages ", " \" $(jq -csR '[{ \" role \" : \" user \" , \" content \" :[{ \" text \" :.}]}]' < '${file}') \" ", " --query ", " output.message.content[*].text ", " --output ", " text " ] , " presentation ": { " clear ": true , " close ": false , " echo ": false , " focus ": true , " showReuseMessage ": false } , " problemMatcher ": [] } ] } 実行方法 では実際に Visual Studio Code から Amazon Bedrock を呼び出してみます。 Visual Studio Code を起動します。 空のテキストファイルを作成し、生成 AI へ送信するプロンプトを記述します。例として以下の内容を prompt.txt という名前で保存します。 素数を小さい方から5個教えてください。 先ほどの prompt.txt を開いたままコマンドパレットを開きます。 Tasks: Run Task と入力します。 bedrock を選択します。すると prompt.txt の内容が Amazon Bedrock へ送信されます。しばらく待つと Amazon Bedrock からレスポンスが返ってきて表示されます。 はい、素数を小さい方から 5 個お教えします。 1. 2 2. 3 3. 5 4. 7 5. 11 これらが最小の 5 つの素数です。 補足説明: - 素数とは、1 とその数自身以外に約数を持たない自然数のことです。 - 1 は慣習的に素数とは見なされません。 - 2 は唯一の偶数の素数です。 - これらの数以降の素数は 13, 17, 19, 23...と続きます。 解説 何を行っているのか解説します。 Visual Studio Code には外部ツールを呼びだす機能があります。これを使って AWS CLI を実行しています。 Tasks in Visual Studio Code 実行されるコマンドは以下のとおりです。 aws bedrock-runtime converse \ --model-id anthropic.claude-3-5-sonnet-20240620-v1:0 \ --messages "$(jq -csR '[{\"role\":\"user\",\"content\":[{\"text\":.}]}]' < '${file}')" \ --query output.message.content[*].text \ --output text aws bedrock-runtime converse は Amazon Bedrock の Converse API を呼びだすためのコマンドです。 --model-id には使用する基盤モデルの ID を指定します。 今回は Claude 3.5 Sonnet を使用しています。利用可能な基盤モデルは Supported foundation models in Amazon Bedrock - Amazon Bedrock をご参照ください。 --messages には Converse API に送信するメッセージを指定します。 ${file} は Visual Studio Code によって現在開いているファイルのパスに置換されます。詳しくは Visual Studio Code Variables Reference をご参照ください。 jq を使って現在開いているファイルの中身を Converse API に送信するメッセージへ変換します。例えば先ほどの実行例の場合、以下のようなメッセージに変換されます。 [ { " role ": " user ", " content ": [{ " text ": " 素数を小さい方から5個教えてください。 " }] } ] --query output.message.content[*].text --output text で aws bedrock-runtime converse コマンドの実行結果のうち基盤モデルによって生成されたテキストメッセージのみを抜き出して表示しています。 おわりに この記事では Visual Studio Code から AWS CLI を使って Amazon Bedrock の Converse API を呼びだす方法をご紹介しました。これによりエディタからブラウザの生成 AI サービスへプロンプトをコピー&ペーストする手間を省くことができます。 残念ながらこの方法では生成 AI との単発の受け答えしか行えません。もし生成 AI との対話(複数回の受け答え)が必要な場合は従来通りブラウザから生成 AI サービスを利用するのがよいでしょう。 また今は生成 AI サービスを利活用したエディタ(例: Cursor )や Visual Studio Code 拡張機能 (例: GitHub Copilot 、 Cline )も存在します。エディタと生成 AI サービスをより高度に連携させたい場合はそれらの利用を検討するとよいでしょう。 最後までお読みいただき、ありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆: @shibata.takao ( Shodo で執筆されました )
こんにちは、グループ経営ソリューション事業部の 米久 保です。 はじめに リファクタリングとは リファクタリングの定義 振る舞いのサイズ 振る舞いと自動テストとの対応 リファクタリングテクニック リファクタリングサイズ 技術的負債はどうして生まれるのか コードの守備範囲 変更への対応 技術的負債を返済する 早い返済が吉 新規開発時 変更時 開発チームの裁量で返済する 説得方法 大規模なリファクタリング まとめ 参考文献 はじめに 「 リファクタリング をする時間がない」「 リファクタリング の必要性を関係者に説得しなくてはならない」という悩みをよく聞きます。 リファクタリング という用語が広く普及した結果、意味の希薄化が発生し、元来の意味と異なる使われ方を目にすることもあります。また、似通った用語としてリアーキテクティングというものがあり、混同されがちです。 リファクタリング の課題と向き合い、それらを解消するための正しいアプローチを取れるようになるには、 リファクタリング に対する理解を深めることが重要です。本稿では、最初に リファクタリング の定義を確認します。そして リファクタリング を必要とする技術的負債がどのように生まれるのか、それを計画的に返済するにはどうすべきかについて述べます。 リファクタリング とは リファクタリング の定義 Martin Fowler 氏の有名な著書[1]では、 リファクタリング は以下のように定義されています。 リファクタリング (名詞) 外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること。 リファクタリング する(動詞) 一連の リファクタリング を適用して、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること。 リファクタリング という用語のあいまいな使用については氏も以下のように述べています。 長年にわたって、業界では「 リファクタリング 」という用語を、コードをきれいにするあらゆる作業を指すものとしてあいまいに使ってきました。しかし、上記の定義では、コードをきれいにするための特定の手法であることを示しています。 リファクタリング は振る舞いを保ちつつ小さなステップを適用していくことであり、ステップを積み重ねていくことで大きな変化をもたらしていくものなのです。 Kent Beck 氏も最近の著書[2]で以下のように述べています。 「 リファクタリング 」という言葉は、機能開発の長い中断を指す言葉として使われ始めたときに致命傷を負った。「振る舞いを変更することなく」という条項さえもなきものにされ、「 リファクタリング 」は簡単にシステムを破壊できるようになった。 氏の言うように、 リファクタリング という言葉の不用意な使用が リファクタリング に対する共通認識を歪め、健全な リファクタリング 活動を阻害してしまうリスクとなり得ます。次項以降では解像度を上げて リファクタリング を捉え直したいと思います。 振る舞いのサイズ 外部から見た時の振る舞いを変えない ことは リファクタリング における必須要件です。注意すべきは、一口に振る舞いと言ってもそのサイズはまちまちであるということです。ソフトウェアは大小さまざまな構成要素から成り立ちます。設計の抽象度で捉えると、下図のように4つの抽象レベルに分けて考えることができます[3]。 アーキテクチャ 、あるいは アーキテクチャ を土台として実現されるソフトウェアは、求められる機能要求や品質特性を包括的に提供します。 モジュール は、 ユースケース やその一部を実現する振る舞いを提供します。ユーザー目線で何らかの意味をなす振る舞いだと言えるでしょう。 コンポーネント は、モジュールにおける部分的な振る舞いを提供します。税計算処理のように ドメイン 知識に対応する振る舞いもあれば、データの永続化のように技術的な振る舞いもあります。 クラス ( 関数型言語 であれば関数)が提供するのは最小単位の振る舞いです。 振る舞いと自動テストとの対応 外部から見た振る舞いを変えないという条件を満たす上で重要な役割を果たすのが自動化されたテストです。コードを直しても変わらずテストが通過(Pass)することで、振る舞いが壊れていないことを確認し、安心して リファクタリング を行うことが可能となります。 さて、振る舞いにサイズがあるように、自動テストにもサイズがあります。どのサイズのテストをどの程度行うべきかの方針立てを テスト戦略 と呼びますが、テストピラミッドはその代表的なパターンです。よりサイズが小さく、実行コストの低いテストの比率を高くするという考え方です。 振る舞いを実現するソフトウェア構成要素と、テストピラミッドの対応付けを次の図に表します。 テストピラミッドはテストタイプ( ユニットテスト /インテグレーションテスト/E2E)を用いて表現することもありますが、ここではテストサイズ[4]を用いて表現しました。モジュールに対するテストは、データベース等のプロセス外通信を実際に行うか、テストダブルで代替するかによってSmallにもMediumにもなり得ます。 テストピラミッドをベースとしたテスト戦略を前提とすると、図の上位に行くほどテストによって固定できる振る舞いの量は少なくなります。Largeサイズのテスト(主にE2Eテスト)だけでは、ソフトウェア全体としての包括的な振る舞いに対して機能退行( リグレッション )を漏れなく検知することはできません。下位のテストによってより詳細な振る舞いが担保されることを前提とします。 アーキテクチャ /ソフトウェアの抽象レベルでは、定義どおりに リファクタリング を行うことは実質困難なので、リアーキテクティングという用語を用いるのが妥当でしょう。たとえば、モジュール境界の引き方や相互作用の見直し、一部モジュールのマイクロサービス化などがリアーキテクティングに該当します。 リファクタリング テクニック 本稿において、 リファクタリング とは設計の抽象レベルのうちクラス、 コンポーネント 、モジュールのレベルにおいて適用可能なものであると考えます。次に、 リファクタリング テクニックについて考えてみましょう。 書籍[1]には多くの リファクタリング テクニックがカタログ化されています。その多くは、「 関数の抽出 」、「 ループの分離 」のような単一クラス内またはメソッド内に閉じたものです。「 ポリモーフィズム による条件記述の置き換え 」、「 サブクラスによるタイプコードの置き換え 」のような複数のクラスにまたがるものも一部あります。前者のテクニックの中には、 IDE の機能を使ってワンクリックで実施できるものも多くあります。 書籍[5] では、 デザインパターン を適用してコードを改善する、パターン指向の リファクタリング テクニックが紹介されています。そのほとんどが コンポーネント レベルのものです。 モジュールレベルの リファクタリング については、私が知る範囲では体系立てられたテクニック集は見当たりません。この抽象レベルでは複数 コンポーネント の協調によって ユースケース 相当の振る舞いを実現しますが、パターン化できるテクニックが少ないからかもしれません。中核ロジックと処理フローロジックの分離[3]や、SOLIDなどの原則の適用によって設計を洗練させることは可能ですが、小さなテクニックの 機械的 適用を超えたより高度な知的作業が求められます。 なお「 リファクタリング したくてもそもそもテストコードが存在せず、テスト容易性も低い」レガシーコードにどう立ち向かえばよいかについては、書籍[6]が参考となるでしょう。 リファクタリング サイズ 以降の議論のため、 リファクタリング のサイズを下記表のとおり3つに分類します。 リファクタリング サイズ 設計の抽象レベル テストサイズ リファクタリング テクニック 所要時間 Small クラス S 小さなステップ 短い Medium コンポーネント S パターン指向 比較的短い Large モジュール S または M - 長い 技術的負債はどうして生まれるのか 仮に熟練した プログラマー がきれいなコードを書き上げたとしても、時間経過とともに内部品質が劣化することは不可避です。なぜでしょうか。 コードの守備範囲 最初に完成したコードは、その時点で判明している振る舞いに適合した設計となっています。その振る舞いの中にある類の可変性が存在するなら、その軸において柔軟性を持っているはずです。たとえば、「サブクラスによるタイプコードの置き換え」の リファクタリング を適用していれば、サブクラスや Enum 列挙子によって新たな振る舞いを追加可能となっているでしょう。SOLID原則のひとつであるOCP(オープン・クローズドの原則)による拡張性です。 このように、コードには変更に対して コスパ よく柔軟に対応可能な範囲、いわば 守備範囲 があります。 変更への対応 守備範囲内の変更であれば、変更を実現するにあたって リファクタリング は不要か、最小限で済ませることができます。問題は、守備範囲外の変更が発生したときです。 その場合、既存の設計はその変更に対する柔軟性を持ち合わせていないので、取りうる選択肢は以下の2つです。 リファクタリング により柔軟性を持たせた上で変更を行う その場しのぎのパッチワーク的な対応を行う プログラマー 倫理に従えば前者の一択なのですが、実際には トレードオフ が発生し判断を求められます。守備範囲外ということは、既存の設計では想定できていなかった類の変更だということなので、 リファクタリング には一定のコストが生じます。それに変更そのもののコストを加えたトータルのコストが、 変更によって得られる便益の向上と比較して正当化できるか という話になるのです。 もちろん個々の変更案件毎ではなくプロダクトやサービス全体として中長期で費用対効果があるかという判断基準も大事です。しかし、その変更を素早くリリースすることがビジネス的に重要である場合に、以下のような判断は果たして間違っていると言えるでしょうか? 「本来 リファクタリング をすべきですが、影響範囲を考えて今回はパッチワーク的な対応をしました」 「本来 リファクタリング をした方がよいと思いますが、影響範囲を考慮して今回はプルリクを承認します」 技術的負債を返済する ソフトウェア開発におけるあらゆる設計判断は、最終的にビジネス上の何らかの価値につながるべきです。そう考えるならば、一時的に技術的負債を許容することも判断としては正当化されます。重要なのは、 技術的負債の発生を認識することと、それを管理していくこと です。 早い返済が吉 パッチワーク的な対応を行うと、設計にほころびが生じます。このほころびは容易に積もり積もるだけでなく、やっかいなことに相互干渉する場合もあります。10回のパッチワーク的な対応を行ったら、技術的負債の量は10 ではなく50や100にもなり得るということです。技術的負債は 複利 であると考え、手遅れになる前に計画的な返済が必要です。 新規開発時 新しい機能を新規に開発する際は、可能な限りコードをきれいにし、技術的負債を生まないことが前提となります。新規開発時点で乱雑なコードが、その後きれいに リファクタリング される可能性は残念ながら非常に小さいです。 最も効果的な方法は テスト駆動開発 (TDD)のプ ラク ティスを採用し、Red - Green - Refactor のサイクルの中で高頻度に リファクタリング を実施することです。とは言え、TDDの習得に一定の修練が必要なのも事実です。最低限、プルリクを出す前には時間を取って リファクタリング しましょう。 変更時 変更に対応する際は、 リファクタリング の要否を検討し、 リファクタリング が必要な場合はそのコストを見積もります。コストが想定を上回る場合は、開発リーダーやプロダクトオーナーと相談しましょう。今すぐ リファクタリング を行うのか、それとも先送りにするかの意思決定が必要です。 先送りにする、すなわち技術的負債の発生を受け入れる判断をしたならば、その返済プランとして バックログ アイテムに リファクタリング のチケットを登録します。 リファクタリング チケットの解消方針はいくつか考えられます。チームとして戦略を定めて、継続的な負債返済を実現しましょう。 規模の大きい変更と併せて リファクタリング を実施する イテレーション の一定のポイントを リファクタリング に割り当てる リファクタリング を中心に行う イテレーション を設ける 開発チームの裁量で返済する リファクタリング に関して、プロダクトオーナーやビジネスサイドへの説得が必要、という課題を耳にします。 私は、サイズがSmallやMediumの リファクタリング は開発チームが自分たちの裁量で実施できるのが望ましいと考えています。そのためには、技術的負債の発生をなるべく小さく抑えつつ、定期的に解消していくプロセスや文化が欠かせません。 次の図は、 JVM などの処理系において GC ( ガベージコレクション )によってメモリが自動解放されるイメージです。アプリケーションに割り当てるメモリが不足すると、参照が切れてゴミとなったオブジェクトが回収され、割り当て可能なメモリが増えます。いよいよメモリが足りなくなると、広範囲を対象としたフル GC が実行されます。フル GC は実行時間が長くなりアプリケーションへ与える影響も大きいため、なるべく回避したいものです。 リファクタリング による技術的負債の返済は、 GC による割当可能メモリの回収に似ています。長い時間を要し、その間開発を止めてしまうような大きな リファクタリング (Largeサイズ)やリアーキテクティングは、なるべく避けたいものです。そのためには、小さい リファクタリング (Smallサイズ、Mediumサイズ)を継続的に実施し、技術的負債を膨らませないことが大切です。 説得方法 とは言え、現時点ではそのような文化が醸成されておらず、 リファクタリング の必要性を認めてもらうために ステークホルダー の説得が必要な場合はどうしたらよいでしょうか? まずはファクトを示す必要があるでしょう。たとえば変更リードタイム、リリース後の欠陥発生率などのメトリクスです。時間経過に伴う推移を示し、緊急かつ重要な課題であることを認識してもらうとよいでしょう。コストとリターンを明確にすることも効果的です[7]。 大規模な リファクタリング Largeサイズの リファクタリング や、リアーキテクティングが必要なときはいずれやってきます。これには相当のコストと期間を要するため、 ステークホルダー を巻き込んだ上でプロジェクトやタスクフォースとして取り組むべきです。プランニングや社内調整、コミュニケーション設計などが包括的にまとめられた書籍[8]は大いに参考となるでしょう。 まとめ 本稿では、 リファクタリング の定義を再確認した上で、 リファクタリング のサイズを3つに分類しました。「 リファクタリング が必要」と漠然と言うのではなく、どの粒度の リファクタリング を指しているのか解像度を上げてコミュニケーションを取ることが、開発業務の計画や進行において重要ではないかと思います。 後半では、技術的負債が生み出される仕組みや、負債に対する取り組み方について述べました。ソフトウェア開発の現実においては一 定量 の技術的負債は発生を回避できないという前提で、戦略的に立ち向かわなければなりません。 参考文献 [1] Martin Fowler 著、児玉公信・友野晶夫・平澤 章・梅澤真史 訳『 リファクタリング (第2版) 既存のコードを安全に改善する』 オーム社 (2019) [2] Kent Beck 著、吉羽 龍太郎・永瀬 美浦 ・細澤あゆみ 訳『Tidy First? 個人で実践する経験主義的ソフトウェア設計』 オライリー・ジャパン (2024) [3] 米久 保 剛 著『アーキテクトの教科書 価値を生むソフトウェアの アーキテクチャ 構築』 翔泳社 (2024) [4] Simon Stewart 氏による記事『 Test Sizes 』 Google Testing Blog(2010) [5] Joshua Kerievsky 著『Refactoring to Pattens』Addison-Wesley(2005) [6] マイケル・C・フェザーズ 著『レガシーコード改善ガイド 保守開発のための リファクタリング 』 翔泳社 (2009) [7] 松岡 幸一郎 氏による記事『 「リファクタリングの時間」を確保する技術 』株式会社ログラス テックブログ(2025) [8] Maude Lemaire 著『Refactoring at Scale: Regaining Control of Your Codebase』O'Reilly Media(2020) 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆: @tyonekubo 、レビュー: @nakamura.toshihiro ( Shodo で執筆されました )
こんにちは。 エンタープライズ 第一本部 戦略ソリューション 1 部の英です。 普段はWebアプリや スマホ アプリの案件などを担当しています。あと、趣味でAIを勉強しています。 2025年1月の組織改編で部の名前がカッコよくなりました。戦略って言葉、好きです。 ITソリューション部(旧)より、戦略ソリューション部(新)のほうが頭良さそうですよね。 気のせいか、名刺もなんだかカッコよくなった気がします。 前置きはここまでにして、今日はFlutterFlowのAI機能の検証をします。 私は普段から軽いデモであればFlutterFlowを愛用しています。爆速で開発できて便利です。 そんな、ただでさえ便利なFlutterFlowになんとAI機能が追加されたので、その実力を試してみようと思います。 ※ 2024年10月のアップデート 追加された機能は以下の4つ。 New Page Creation: 自然言語 や ソースコード からページを生成できる機能 New Component Creation: 自然言語 や ソースコード から コンポーネント を生成できる機能 Sketch To Component:手書きやスクショから コンポーネント を自動生成できる機能 Page Autocomplete:部分的に構築されたページをAIが自動的に補間してくれる機能 さっそく試してみましょう。 1:New Page Creation(自然言語ver) 2:New Page Creation(ローコードver) 3:New Component Creation 4:Sketch To Component 5:Page Autocomplete さいごに 1:New Page Creation( 自然言語 ver) まずはスタンダードな使い方として、 自然言語 による画面生成を試してみます。 適当なプロンプトをChatGPT(4o)に作成してもらい、それを貼り付けます。 では、これらの文章をコピペしてFlutterFlowのNew Page Creationに貼り付けてみます。 PreviewPageを押下すると次の画面が表示されました。 要素としては足りていますが、レイアウトがイマイチだと感じます。 この結果をChatGPTに投げつけて、プロンプトを修正してみましょう。 修正されたプロンプトで再度生成を行ったら、こんな画面が出力されました。 まあ、ほぼ完璧といって良いんじゃないでしょうか。 色合いやフォントを調整すれば十分に使える品質だと思います。 作成された各 コンポーネント は、いつも通りレフトバーから操作することが可能です。 白紙から作成するよりよっぽど効率的ですね。素晴らしい。 2:New Page Creation(ローコードver) New Page CreationはFlutterの ソースコード から作成することもできます。 いや、Flutterの ソースコード があるならそれでええやん!というツッコミは無視します。 というか、FlutterFlowの醍醐味は GUI によるUI/UX設計&ノーコード開発です。論点が違います。 仕上げをFlutterFlowに任せたい という思いが強いです。なるべくコーディングはしたくないのです。 とはいえ、 ソースコード が手元にないと話になりません。v0を使いましょう。 v0については本記事では解説しませんが、 自然言語 でコーディングおよびUIのプレビューまでできちゃう優れものです。 v0に貼り付けましょう。 プレビューは良さそうですね。ただ、Flutterで書いてほしいという命令を忘れていました。Flutter FlowのAIToolsはFlutterで渡した方が精度が高いです。修正してもらいます。 . dart での リファクタリング が始まりました。少し待ちましょう。 こういったダイナミックな変更にも素直に対応してくれるのがAIの良いところです。 もし、これが仕事で相手が人間なら、変更依頼と信頼関係を天秤にかけなければなりません。 複数ファイルに分かれているので、フォルダ構成を伝えつつ、 ソースコード をコピペしてみます。 生成が完了しました。 先ほどのv0のプレビューとソックリ ですね。 テキスト送信のブロックが下に張り付いていないのが惜しいです。 仮ですが、containerをstackでwrapして画面下部に引っ張ってきました。 こうやって手軽に調整が効くのが良いですよね。FlutterFlowを使う意味があります。 3:New Component Creation 先ほどのチャット画面に画像投稿用の コンポーネント を作成することを目指しましょう。 進め方は先ほどと同じように、プロンプトをChatGPTに考えていただき、FlutterFlowに貼り付けます。 長くなるのでChatGPTとのやり取りは省略します。 で、自動生成された コンポーネント がコレです。良いですね。 プレビュー領域もあって使いやすそうです。 4:Sketch To Component この機能を使うには 手書きのイメージが必要 になります。 電通 総研の画伯として一筆描くとしましょう。 うおぉぉぉおぉぉぉぉ!!! サササササッ..ササ..!!シュッ!! カリカリカリ...ツー...トントンッ! 描けました。なかなかの出来栄えです。 この画像から コンポーネント を作成してみましょう。 完璧すぎて草。 用途としては、会議室のホワイトボードに殴り書きしたイメージを具現化するなどでしょうか。 5:Page Autocomplete さて、最後です。作りかけの画面に 自然言語 で修正を加えられる機能です。 先ほどのチャット画面を作りかけとして定義し、作りこみをしてみます。 チャット送信で添付ファイルを追加できるようにしてみましょう。 Page Autocompleteを押下すると、 現在の画面構成を 自然言語 (英語)に起こしたもの が表示されます。 その内容をChatGPTに伝えて、修正命令を考えてもらいます。 ChatGPTが考えた修正命令を張り付けて、Page Autocompleteを開始しました。 ファイル添付のアイコンが追加されました。 これは修正の提案であり、その内容をどれくらい受け入れるのか を選択できます。(Less←→More) 今回はMoreに振り切って受け入れてみます。 反映後の画面がこちらです。 ファイル添付が出来そうなUIに修正されていることが分かります。 このように、修正箇所を細かく指示しながら、少しずつ画面を作りこんでいくことができます。 さいごに さて、今回はFlutterFlowのAI機能について記事を書きました。 *1 個人的な感想を言うとイマイチな性能でした。全体的にpaddingに気を遣えていないのが残念。 これは私の命令の内容が悪かったのか、AI側の性能が悪かったのか。 時間があるときにもっと検証してみようと思います。 これからも AWS やAI関連の検証記事をたくさん書いていきます。 ↓ のスターを押していただけると嬉しいです。励みになります。 最後まで読んでいただき、ありがとうございました。 エンタープライズ 第一本部では一緒に働いてくださる仲間を募集中です。以下のリンクからお願いします。 私たちは一緒に働いてくれる仲間を募集しています! 中途採用-エンタープライズ第一本部 新卒採用-エンタープライズ第一本部 執筆: 英 良治 (@hanabusa.ryoji) 、レビュー: @yamashita.tsuyoshi ( Shodo で執筆されました ) *1 : ※本記事に使用されている画像は、AI画像生成ツール「DALL·E」を使用して作成されています
こんにちは。クロス イノベーション 本部 AI トランスフォーメーションセンター 所属の村本です。 私は普段、 Know Narratorシリーズ の開発や、生成AI関連の技術検証などに取り組んでいます。 今回は、タイトルの通り私の作業環境について紹介します。 私は業務のほとんどを在宅で行っており、作業環境がほぼそのまま生活空間にもなっています。そのため、快適に仕事ができる(暮らせる)ような環境にしているので、作業環境について悩んでいる方の参考になればと思います! 仕事も生活もしやすい環境を目指して アイランド型のデスク配置で壁を背中に デスクになるべくモノを置かない 昇降デスクでときどき立つように モニターはType-C接続できる27インチを2枚(メインの4Kモニターとゲーム対応のWQHD 180hzモニター) ガジェット類の簡単な紹介 作業環境にこだわった結果 まとめ 仕事も生活もしやすい環境を目指して 作業環境、デスク周りがほぼ生活空間であると書きましたが、実際には以下のような目的で利用しています。 仕事 食事 映画などの動画鑑賞 ゲーム 家にいる間は基本デスクにいると言っても過言ではないですね... アイランド型のデスク配置で壁を背中に 早速ですが、作業環境の実際の写真を。(いろいろと趣味要素が写っているのは無視してください) 最大の特徴はアイランド型のデスク配置をして壁を背中側にしていることだと思います。以前は壁にデスクをつけていましたが、モニターの後ろがすぐ壁になっているためか、少し圧迫感を感じていました。この圧迫感を回避するために、アイランド型のデスク配置を採用したのです。 結果的にこの配置は大成功で、圧迫感を感じなくなりました。1日の大半を過ごすのに圧迫感を感じるかどうかは大きな違いだと思います。 そして、 圧迫感がなくなったことにより、作業効率が上がったような気がします。 ※検証はしていません。気分の問題です。気分が大事なのです。 また、壁を背にしたことによって、カメラを付けてオンライン会議を行う際に後ろを気にする必要がなくなりました。仮想背景は使っているのですが、物理的にも気にしなくてよくなったのは思わぬメリットです。 デメリットもあげておくと、「部屋のスペースを使うこと」、「ケーブルが目立ちやすいこと」の大きく2つだと思います。 1点目に関しては、私の場合、家にいるときは基本的にデスクにいるか寝ているかなので問題ありませんでした。たまーに筋トレをすることがあるのですが、そのスペース分は空いているので問題ありません。 2点目に関しては、ケー ブルトレ イや、配線カバーやケーブルを束ねるアイテムを利用して目立たないようにしています。上の全体写真でもほとんどケーブルが見えていないと思います。ケーブルがごちゃごちゃしているのは好きでないので、可能な限りまとめました。このあたりの整理グッズは比較的安い値段で調達可能なのでおすすめです。 ケーブル周りの様子 デスクになるべくモノを置かない 以前はデスクの上にもいろいろとモノを置いていましたが、今は極力モノを置かないようにしています。今使うものだけを置くということを心がけています。 モニター台を利用してモニター下の空間をできるだけ利用したり、デスク上用の棚を利用して本を置いたりしていましたが、これらも圧迫感につながる要因だったかなと思います。 利用頻度の低いものは周囲のラックに置くようにして、使うときだけ取りだすようにしました。こうすることで、デスクを広々使うことができますし、使わないものは空いているスペースに一時的に動かすことも簡単です。 普段の目線からの写真を載せようかと思ったのですが、部屋がしっかり写ってしまうので真上から撮影。 置いてあるものは、 ペン立て ミニトレイ(一時的に小物を置くところ) フェイクの草(プラスチック製) ディフューザー モニター キーボード マウス ノートPC(スタンドで立てている) です。 個人的なお気に入りは草ですね。緑があるだけで少し気分が明るくなる気がします。 ちなみにデスクは奥行き70cm、横幅140cmのものを利用しています。昔奥行きが60cmのものを利用していたのですが、微妙に狭く感じて70cmにしました。このサイズで現状不満はないです。 昇降デスクでときどき立つように デスクはFlexispotの「E7 pro」という電動昇降デスクを利用しています。ボタン1つで、デスクの高さを変えられる便利なアイテムです。電動昇降デスクは在宅ワーカーが1度は夢見るアイテムだと思っていて、社会人5年目のタイミングで思い切って購入しました。 定期的に立って仕事をしたり、会議の時に立った状態でオンライン会議に参加したりしています。立つことで気分転換になりますし、座りっぱなしは良くないですからね。 また、座っている状態でも、座り方や椅子の高さ次第でデスクの高さを変えることはあります。仕事の時はもちろん、ゲームの時や映画をゆっくり見たいとき、様々なシチュエーションに合わせて高さを変えられるのは魅力です。 ちなみに椅子は エルゴヒューマン の「 エルゴヒューマン プロ」を利用しています。最近「 エルゴヒューマン プロ2」が出ているので、これから買う人は2をお勧めします。 モニターはType-C接続できる27インチを2枚(メインの4Kモニターとゲーム対応のWQHD 180hzモニター) 作業環境で気になるポイントの1つがモニターの構成だと思います。私もいろいろな構成を試してきました。もともとは1つの大きなモニターで良い派だったのですが、現在は同じサイズのモニターを2枚使っています。理由は、コミュニケーションツール(Teamsなど)を開きっぱなしにしておきたいのと、オンライン会議時に共有している画面とそうでない画面を分けたい欲が出てきたからです。 基本的には、メインモニターの27インチ4Kのモニター上で作業しつつ、サブモニターのもう1枚でTeamsなどを開くようにしました。複数枚利用すると、どうしても首を振るので疲れてしまいます。その対策として、メインとサブの役割を明確にして、基本はメインしか見ないという形にしました。(写真でもメインモニターがキーボードの前にあるのが分かると思います) ちなみに、メインのモニターは4Kの拡大率125%で利用中です。チームメンバーには4Kモニターを拡大率100%で利用している人もいるようですが、さすがに小さくなりすぎるので自分には無理でした。また、モニターは2つともType-C接続で映像出力、給電可能なモデルなので、ノートPC周りのケーブルが少なく済んでいます。 2枚のモニターに対しType-Cで接続している様子 見出しに「ゲーム対応のWQHD 180hzモニター」と書いていますが、サブモニターはゲーム用としても利用しています。PS5やSwitchでしか利用していないので、180hzに対応していれば十分な性能かなと。 ガジェット類の簡単な紹介 エンジニアとして働いていますので、一応キーボードやマウスなども簡単に紹介しておきます。 キーボードはKeychronの「 Q1 Max QMK/VIA JIS(バナナ軸)」を使っております。持ち運び用にKeychron「K3 Pro QMK/VIA(バナナ軸)」を持っていますが、家では、Q1 Maxを使っています。エンジニアですが、US配列は使えません。US配列使っている人はデキるエンジニアのイメージがありますが、JIS配列でもやれるんだぞというところを見せたいと思います。 マウスは Logicool の「MX MASTER3s」を使っています。マウスといえば トラックボール タイプも良いと聞くのですが、現状こちらで満足しているので変える予定はないです。マウスも持ち運び用があり、同じく Logicool の「MX Anywhere 2S」を使っています。こちら7年くらい使って、落としまくってますが全く問題なく使えています。 上が自宅用セット、下が持ち運び用セット 作業環境にこだわった結果 このように作業環境にこだわった結果、ストレスの少ない快適な作業環境になっていると思います。いろいろ試行錯誤を重ねてきた中でかなり満足のいく環境です。 ただ、いくつかデメリットがあるので注意が必要です。 終わることのない、 PDCAサイクル にハマる 別の環境になると気分が下がる 1点目、どれだけ納得のいく作業環境になっても、時間がたつと気になることが出てきて改善したくなるんですよね。こんなところで PDCAサイクル は回したくないものです。 2点目、普段の環境を自分に最適化しすぎると、別の環境になった時に「あれもない」「これもない」と感じてしまいます。「弘法筆を選ばず」と言いますが、全く持って逆の状況です。「弘法でもないのに筆選びまくり」状態です。 とはいえ、デメリットを感じる時間は、メリットを感じる時間に比べはるかに少ないので問題ないかと思います。 まとめ 今回は、私の作業環境を紹介しました! これからも作業環境の改善は続けると思いますが、作業環境をどう整えていくか悩んでいる方の参考になれば幸いです ご覧いただきありがとうございました! 私たちは共に働いていただける仲間を募集しています! みなさまのご応募、お待ちしています! 株式会社 電通総研 新卒採用サイト AI系プロジェクトマネージャー/リーダー AIサービス開発エンジニア 執筆: @naoki.muramoto 、レビュー: @miyazawa.hibiki ( Shodo で執筆されました )
初めまして。 エンタープライズ 第一本部の佐藤悠です。 本記事では AWS Certified Solutions Architect - Professional(以下:SAPro)をほとんど業務経験のない新人の私が、勉強のみで取得した 経験談 を紹介します。 想定読者は AWS Certified Solutions Architect - Associate(以下:SAA)を取得済みの方です。未経験の場合はSAAからの取得をお勧めします。 目次 著者背景 SAProとは 取得理由 学習方法 試験概要 学習教材 CloudLicense Udemy AWS Certified Solutions Architect Professional Practice Exam 方法 テスト当日 まとめ 著者背景 大学や院ではほとんど情報をやっていない 基本情報取得(入社後) 新人1年目 インフラ業務にまつわる OJT 課題を1か月間実施 2週間で AWS Certified Cloud Practitioner(以下:CLF)を取得 1か月でSAAを取得 インフラの知識はなかったので、試験対策を行う中で学習をしました。CLFの試験勉強を始めた当初は IPアドレス のネットワーク部と ホスト部 の概念を知らないくらいのレベルです。 SAProとは AWS Certified Solutions Architect - Professional は、 AWS での クラウド アーキテクチャ の設計とデプロイにおいて2年以上の実践的な経験を持つ個人を対象とするものです。 対象となるレベルは以上のようになっており、業務経験がない人が学習を行うと分からないことの量、試験範囲の広さや問題のボリュームに挫折してしまうと思います。したがって、未経験者の方は50~100時間ほどコミットすることを覚悟して、学習する時間を確保する必要があります。ただ2年以上の実務経験は受験のための必須条件ではないので、未経験で取得出来たら2年分の 知識 を獲得できるチャンスでもあります。 複雑な問題に対する複雑なソリューションの提供、セキュリティ、コスト、パフォーマンスの最適化、および手動プロセスの自動化における高度な知識とスキルを証明するために役立ちます。 この資格を取得することによって得られる知識は以上のようになっています。問題も詳細は後述しますが、想定される課題に対して複数のサービスを組み合わせたシナリオにおいて、最も効率的なものを選択する形式であるため、用意された選択肢から選ぶということ以外は実践的であると感じています。 取得理由 SAProはSAAに比べてさらに具体的で実践的な ユースケース や課題に対処するような出題形式をとっていたので、試験対策を通じて課題解決のための手法を深く理解できるのではないかと考えたのがきっかけです。 また、新人で最上位資格を保持していることで AWS に関しては他の人と差別化できて自分がやりたいインフラの仕事に立候補できると考えました。これがあきらめかけた時の支えになっていました。 学習方法 試験概要 試験の概要は以下のとおりです。 SAAに比べて試験範囲がわずかに狭くなり頻出の分野が特定しやすいですが、その分問われる内容は深くなっており、要求される正答率も高くなるので試験の難易度は難しくなっていると感じました。 内容 複雑な組織への対応 ソリューション設計と継続的改善 移行とモダナイゼーションの加速 出題形式 選択肢から単一または複数選択をする形式 時間 180分 問題数 75問 合格点 75% 学習教材 以下の学習教材をお勧めします。 CloudLicense メリット 日本語に違和感がなく解説が詳しい 本番で出る内容が多かった デメリット 問題文をコピーできないので間違えた問題をまとめるには手打ちが必要 https://cloud-license.com/ F12キーを用いて問題文のテキストブロックをコピーできるので許容はできますが、やや手間でした。 Udemy AWS Certified Solutions Architect Professional Practice Exam メリット 本番でほぼ同じ内容が問われた コピー&ペーストが可能 デメリット 英語の問題文を google翻訳 にかけると意味不明な時がある https://www.udemy.com/course/aws-certified-solutions-architect-professional-aws-practice-exams こちらは変な翻訳を原文を見て補正する作業が出来れば問題の雰囲気が近いので良い教材だと思います。 方法 以下の試験問題のサンプルをもとに学習方法を解説します。 https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sa-pro/AWS-Certified-Solutions-Architect-Professional_Sample-Questions.pdf このような形式で問われるので「背景」「現状」「要求」に分離します。 この3要素に綺麗に分離できないこともありますが、ざっくりと切り分けることで問題文の見通しが良くなります。大体の場合は文末にある要求の部分に目を通してから、背景と現状を理解することで要求に対する課題がどの点にあるかを把握しやすくなるということです。 このサンプル問題を例に考えます。 要求は過剰な支出を防ぎ、各アカウントのコン トロール を維持するソリューションを提案することです。 背景は攻撃者による インスタンス の起動で請求が高額になったことです。 最後に、現状はセキュリティ侵害には対応したが過剰な支出を防ぐソリューションはないということがわかります。 この時の要求を満たすにはセキュリティ上の問題は考慮しなくていいということが分かり、この長い問題文でも読むべきは後半部分に限定できたので大分見通しが良くなりましたね! そのあとで、選択肢を見ていきます。 この条件を満たす選択肢はCですが、私はそれ以外の選択肢が違う理由も解説できないと解けたことにしませんでした。 解説や公式ドキュメントを参考にしながら、問題がどの分野に属するものかとどのサービスに関連するものかを分類して以下のようにmdファイルでメモをまとめていきました。 VScode の環境下で見出しの 命名規則 を決めて静的解析の 拡張機能 を使用すると、同じ見出しがある際には警告が出るので情報を一つの場所にまとめることができます。 学習のコツとしてはドキュメントを写さないことです。分からないことを写すのは負荷が小さいので記憶に残りづらい気がします。なので、問題を解くためのドキュメントを読み込んだ後にノートをまとめる際には参考資料を見ないようにします。つまりインプットとアウトプットは分離するということです。 以上の方法で先述の問題集を解きます。この方法でやると時間がかかりますが質を高めれるため、200問前後で合格できると思います。私が実際に解いたのも210問でした。 テスト当日 テストセンタで受験しました。 試験時間は長いので事前にトイレに行くことをおすすめします。 問題を半分解いたら休憩してください。 せっかく受験するのですから、太刀打ちできない問題も選択肢から絞って回答できるようにしましょう。 この選択肢のパターンの場合はAとB、CとDとEに選択肢を分けることができ選択肢を2つ選ぶ際にはそれぞれ1つずつ選ぶ 傾向があります 。 またサンプル問題にはなかったのですが、以下のような選択肢の場合 A ) CloudFrontを使用して~ B ) CloudFrontを使用して~ C ) CloudFrontを使用して~ D ) S3で静的ウェブサイト ホスティング をして~ これはA~Cに正解があることが多いです。 結局、この傾向が分かるくらい問題解いていると普通に試験合格できるのですが、どうしても時間がなくて選択肢から逆算したいときに参考にしてください。 そして、あくまで傾向なので切羽詰まった際の参考程度でお願いします。 まとめ AWS 試験のなかで一番難しかったですが試験対策の過程で通常のハンズオンでは検証が難しい内容、例えばControl Towerなどの組織管理に関する部分をシナリオに基づいた課題を解決することで理解出来たので合格自体もそうですが、それまでのプロセスに意味があったなと感じる試験でした。 未経験だと厳しい道のりでつらいですが、合格はできるので同じ境遇の人は頑張ってください! ここまで読んでいただきありがとうございます。 一人でも多く AWS の認定試験に興味を持ち合格していただけたら嬉しいです。 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 新卒採用サイト 執筆: @sato.yu 、レビュー: @nakamura.toshihiro ( Shodo で執筆されました )
はいどーもー! エンタープライズ 第一本部の宮澤響です! (組織改編の影響で部署名が変わりました!) 本記事では、現役のIT企業社員(新卒5年目)という立場から、大学入学共通テスト(旧: 大学入試センター試験 )に今年度から新たな出題科目として設定された「情報Ⅰ」の試験問題を解いてみた感想をお伝えします! 問題・正解 感想 解答者として 大問1 大問2 大問3 大問4 IT企業社員として おわりに 問題・正解 本記事の対象は、令和7年度の本試験問題となります。 問題および正解は、以下に公開されています。 問題PDF (遷移先: 毎日新聞 デジタルWebサイト)※ 正解PDF (遷移先: 独立行政法人 大学入試センター Webサイト) ※公開され次第、 独立行政法人 大学入試センター Webサイトのものに更新予定です。 感想 (以下、当然ですが全て個人の感想です!) 解答者として 何よりもまずみなさまにこれだけは伝えたいという感想として、 「情報Ⅰ」で受験生に求められているものは、「情報学の知識」ではなく、「情報を読み取る/活用する能力」なのかな と感じました。 もちろん、後述の大問1 問1 aのように、情報学の知識を問う問題も含まれてはいるのですが、問題の大半は 「記載された文章や図表の内容を正確に理解し、そこから分かること/考えられることを解答する問題」 でした。 いわゆる「問題文の中に答えがある」タイプの問題です。 その意味では、情報学というよりは日本語と論理的思考力の問題といえるのかもしれません。 私自身、こうして実際に問題を解くまでは「プログラミングやネットワークのような情報学的な問題が多いのかな?」というイメージをもっていたため、そのイメージは見事に覆されました。 「 SNS をはじめとするインターネット上の情報に振り回されることなく、情報を正しく理解・活用してほしい」という 大学入試センター の思いが込められているのかもしれません。(?) ということを踏まえまして、以下、大問の一部を抜粋しての雑多な感想です。 大問1 記念すべき1問目、大問1 問1 a、いきなり「デジタル署名」なんて単語が飛び出してきました! 問題を見る限り、少なくとも「デジタル署名を利用することで、情報の発信者が本人であるかと、情報が改ざんされていないかを確認できる」ということを、今どきの高校生は既に理解しているようです。 もうね、びっくりですよね! 私が高校生の頃はデジタル署名なんて知りもしませんでしたし、たとえを耳にしたとしても「 ニンテンドーDS みたいにタッチペンで荷物受け取りのサインができるのかなぁ」くらいにしか考えなかったと思います。笑 大問2 大問2 B、「現金で6,000円ずつ集金する際のおつり」というテーマ設定が単純に面白いなと思いました。 確かに千円札で払う人も一万円札で払う人もいるよなぁと、ちょっとしたあるあるでした。 大問3 人日計算による 工数 計画のようなテーマ設定でした。 そのため、少し「 SIer っぽさ」も感じました。 また、この大問のみ唯一プログラムの話が登場しました。 とはいえ、特定の プログラミング言語 の知識がないと解けないような問題ではなく、ごくごく簡単な アルゴリズム の問題でした。 そのため、前提として必要な知識は「変数」「配列」「代入」という概念のみでした。 大問4 「尺度水準」なんて私は大学に入って初めて学んだのに…やっぱり今どきの高校生は凄い…。 IT企業社員として 数年後の新社会人は、程度の差こそあれ、全員がこのレベルの知識や思考力を有した状態で社会に出てくるわけです。 嬉しいような、ワクワクするような、恐ろしいような、不思議な感覚です。 もちろん、全社会人が共通テストを受験しているわけではありませんが、科目としての情報Ⅰが必修化していることも踏まえると、 情報リテラシー は確実に底上げされていると考えられます。 そのため、新入社員に「そんなことも知らないんですか???」と思われないよう、私自身も学びを継続していくことが大切だなと感じました。 また、私が興味をもっている人材開発的な観点から考えると、新人研修の内容にも影響があるのではないかと感じました。 これは、「現在のIT未経験者」と「数年後のIT未経験者」とでは、前提知識のレベルが大きく異なっている可能性が高いためです。 現在実施されている「現在のIT未経験者」向けの研修の中には、「数年後のIT未経験者」からすると、「そんなの全員高校でやってるし…」と思われる内容が含まれている可能性も否定できません。 そのため、近い将来、弊社に限らず、多くの企業(研修実施側、研修受講側、ともに)がIT系の研修プログラムを見直す必要に迫られるのではないかと感じました。 おわりに 本記事では、令和7年度大学入学共通テストの「情報Ⅰ」の本試験問題を解いてみた感想をお伝えしました。 少なくとも今年度の本試験問題では情報学の知識はそれほど要求されないため、IT業界のみなさまはもちろんですが、それ以外の業界のみなさまや学生のみなさまも、お時間のあるときに解いてみてはいかがでしょうか。 最後までお読みいただき、本当にありがとうございました! 私たちは共に働いていただける仲間を募集しています! みなさまのご応募、お待ちしています! 株式会社電通総研 新卒採用サイト 株式会社電通総研 キャリア採用サイト 執筆: @miyazawa.hibiki 、レビュー: @kinjo.ryuki ( Shodo で執筆されました )
初めまして。 エンタープライズ 第一本部の佐藤悠です。 本記事では Amazon Lightsailを用いて簡単に、 WordPress を用いたブログサーバーを立てる試みを記します。 目次 想定読者 Amazon Lightsailとは WordPressとは ハンズオン(実際にやってみる)でサーバー作成 IAMユーザについて Amazon Lightsailの起動 想定読者 読者想定としてはprogateでHTML/ CSS とか学習したけど、その後にウェブサイトを作るまで何をしたらいいか分からない、発信用のサーバーを作りたいと考えているだけで実行に移せない人向けです。 今回のサーバーを立てる場合には AWS アカウントの登録と、そのまま継続して環境を使用する際には毎月5ドル程度の出費が想定されます。ご了承ください。 Amazon Lightsailとは 以下公式サイトより https://aws.amazon.com/jp/lightsail/ Amazon Lightsail は、使いやすい仮想プライベートサーバー ( VPS ) インスタンス 、コンテナ、ストレージ、データベースなどを費用効果の高い月額料金で提供します。 これが基本的な内容説明になりますが、今回利用する特性は以下の部分。 数回クリックするだけで、ウェブサイトやアプリケーションを作成できます。ネットワーク、アクセス、および環境を自動的に設定します。 これが本当に数クリックで終わります。 サーバーを立てるところを飛ばして学習できるという良さを感じることができると思います。 WordPress とは 以下公式サイトより https://ja.wordpress.org/ クリエイターや中小企業から大企業にまで、世界中の何百万ものウェブサイトに選ばれている オープンソース のパブリッシングプラットフォームです。 多くの利用者が存在しており、コミュニティが発達しているのでわからないことがあった際にググればたいてい解決できる強みがあります。 ローコードで、ほとんどコードを書かなくてもいいのでブログくらいならあまり手間をかけずに作成できます。 当然HTMLも直接記述できるので、ローコードの仕様を理解するだけにとどまらないところが学習教材にあっていると思います。 以上の理由から、 Amazon Lightsailで立てたサーバーで WordPress を使用するのが楽にWebサイト作成に入門できると考えます。 ハンズオン(実際にやってみる)でサーバー作成 それでは、実際に手順を示しながらサーバーを作成します。 IAMユーザについて まずは AWS アカウントを作成してください。 https://aws.amazon.com/jp/register-flow/ 以上の手順を参考にアカウントを作成します。 ここで作成したルートアカウントに 不正アクセス されると AWS 上でできる全てを実行できてしまうので、以下のドキュメントを参考にMFA(多要素認証)をアカウントで有効にします。 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html#enable-virt-mfa-for-root このルートアカウントは権限が強すぎるため、IAMユーザーを作成します。 IAMユーザーとは以下の図の通りで、現在作成したルートユーザーが権限の範囲を限定したユーザーを作成することが必要になります。 管理者が権限を限定したIAMユーザーを作成して、そのユーザーとして操作を行います。今回の場合は管理者もユーザーも自分になるのでこの意図が分かりづらいですが、意図しない操作を権限を弱めることで強制的に禁止し、安全にリソースを作成・使用するための措置です。 Amazon Lightsailの起動 AWS マネジメントコンソールの画面で、以下の画像のように検索窓でLightsailと検索し、表示されたアイコンを押下します。 次に以下の画面でCreate instanceを押下します。 遷移先ページで以下の表示があるので Linux 上で WordPress を動かすための写真のようなシンプルな構成を選択します。 次に ssh キーの生成を選択する部分があるので表示にしたがって実行します。 ssh キーのダウンロードが走りますが、このファイルの 削除 や 公開 をしないでください。 PC上の安全な場所で保存するようにしてください。 続いて以下のように インスタンス (使用するサーバー)選択をします。 正直一番小さいサイズの$5のものを選ぶのが経済的でいいと思います。 最後に インスタンス に名前を付けて作成を押下するとサーバーは完成です。 以上のような操作にてサーバー自体を作成することができました。 次回は完成したサーバーに HTTPS でアクセスできるようにする方法を解説し、実際にブログを作成できるようになるための具体的な操作を紹介します。 ご覧いただきありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 新卒採用サイト 執筆: @sato.yu 、レビュー: @nakamura.toshihiro ( Shodo で執筆されました )
初めまして。 エンタープライズ 第一本部の佐藤悠です。 本記事では AWS Solution Architect Associate(以下:SAA)を受験料のみで取得した 経験談 を紹介します。 読者想定としてはCloud Practitionerを取得した後にSAAの取得を考えているかつ コスパ 良く学習したい人向けです。 目次 著者スペック 受験の理由 学習方法 学習教材(無料の教材を知りたい人向け) テスト当日 まとめ 著者の経歴 大学や院ではほとんど情報をやっていない 基本情報取得(入社後) 新人1年目 インフラ業務にまつわる OJT 課題を1か月間実施 Cloud Practitionerを取得 勉強は苦手 資格取得の勉強にかかる金額は安く済ませたい! OJT 課題は、EC2/RDS インスタンス を作成しCloudWatchで監視して SNS で通知するというような環境をInfrastructure as a Code(以下:IaC)で作成した内容ですが、この経験で大きく合格に近づくかといったらそうでもないです。2~3日、初心者向けハンズオンで GUI を触るとすぐに相応の知識は取得できます。 どんなハンズオンかというと以下が良いと思います。 AWS ハンズオン チュートリアル Create and Connect to a Microsoft SQL Server Database with Amazon RDS https://aws.amazon.com/jp/getting-started/hands-on/create-microsoft-sql-db/?ref=gsrchandson&id=updated AWS 環境のセットアップ https://aws.amazon.com/jp/getting-started/guides/setup-environment/?ref=gsrchandson 当然 無料 です。 Cloud Practitionerは可能なら取得しておいてください。後述しますがSAAに対しては段階的なアプローチが必須だと思います。 IaC 余談ですがIaCはその可搬性や再現性に意味があり、コード一発で同質のインフラが構築できたり、修正もコードベースで管理しているので簡単にできたりなどの強みがあります。このロジックを理解することはインフラを理解するにあたって重要です。ただ、再三ですがこの内容はまれにCloudFormationの部分で似た概念が出題されるかも?のレベルなのでIaCに関する知識を深堀りすることが合格の要因にはならないです。 受験の理由 Cloud Practitionerは点的な知識の連続であり、相互の連携が要求されるインフラ業務にはもう一段踏み込んだ学習が必要だなと感じたためです。 特に AWS ではすべてをハンズオンでやっていると無料枠や、個人利用の規模感から逸脱してしまって大変なので試験対策を通じて体系的に理解したいと思いました。 合格後は自分が期待した通りの知識を獲得できていたので取得して正解でした。 あれ?案件のインフラ構成図が理解できる!!!(感動) 火垂るの墓 くらい泣けます。 学習方法 試験概要 内容 サービス間連携と以下を満たすソリューションの選択 コスト最適化 運用上の優秀性 セキュリティ 信頼性 出題形式 選択肢から単一または複数の選択をする形式 時間 130分 問題数 65問 合格点 7割 公式に従うと1年の実務期間が取得者の目安らしいです。 これを学習のみで詰め込むと最低50時間は絶対に確保する必要があります。試験のバージョンがC-03になってからはSAAの難しさが段違いで現在勉強中のSAProとの差が小さいように感じます。 先述したCloud Practitioner取得を勧めるのはこの理由からです。実務経験がない場合は、多分全てがわからない状態で始まるので、最低限の知識なしにいきなりこのレベルにあたるのはハードルが高いです。 学習教材(無料の教材を知りたい人向け) 以下のサイトがとても良いです。 ping -t AWS SAA 最強問題集 https://mondai.ping-t.com/g 無料の会員登録で勉強できるのですが、出題数を絞ったり進行度合いを表示してくれたりと、なんで無料なんだろうと思うくらいです。丁寧な解説も回答の途中で見られるので適当にチェックつけて正解したから、あとで見返せないという心配も必要ない。 これは最強の名にふさわしいです。 ありがとう...「 ping -t」...本当にそれ以外の言葉が見つからない。 こちらの「【試験レベル】Well-Architected Frameworkに基づいた設計」の部分を5問単位で切って解きなおしのスパンを短くすることでストレスなくできます。 私は間違いをメモに丁寧にまとめながら2周で合格しました。 テスト当日 テストセンタで受けました。自宅受験を考えている人はおすすめしません(1敗)。 試験時間は長いのでトイレに行くことと、問題を半分解いたら休憩することをお勧めします。 あと解答に自信がない場合はチェックマークを付けて最後に見直すと他の問題の文脈で語られていたサービスをヒントに解けることがあるので、やってみてください。 まとめ この試験は AWS サービス間の連携など、体系的で意味ある単位での学びになるいい機会だと思います。日常のアイディアが AWS のこのサービスで実現できそう!とかなんで動かないの?に対して予測をつけるのにかなり役立ちます。 試験取得後に自分が実感した変化は、困りごと解決の選択肢が浮かぶようになったことです。 例として、今持っているPCの GPU のスペックが足りないんだけど、これ クラウド 側で レンダリング できないかな?とか、EventBridgeがStepFunctionをキックしないのは権限許可あたりかな?など着想や思考の幅が広がりました。 AWS について詳しくなりたい人は是非、取得を検討してみてください! 最後に ping -tは最強です。これは繰り返し言いたいです。 ここまで読んでいただきありがとうございます。 一人でも多く AWS に興味を持っていただけたら嬉しいです。 そして試験合格を祈ります。 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 新卒採用サイト 執筆: @sato.yu 、レビュー: @yamashita.tsuyoshi ( Shodo で執筆されました )
こんにちは、株式会社 電通 総研の新卒2年目の宮崎 博寿 です。 クロス イノベーション 本部 クラウド イノベーション センターに所属しております。 24年の12月上旬に、世界最大規模の AWS カンファレンス 「 AWS re:Invent」 に参加しましたので、現地で体験した学びや感想、 GameDay の話を中心にレポートします。 re:Inventとは? 一言でいうと、 AWS のすべてが詰まった祭典です。数多くのセッションやワークショップ、ゲーム化された学習イベント(GameDay)、IT各社主催のExpoなどが同時多発的に行われます。 現地の熱気や規模感は想像以上で、 AWS がどれだけ世界に インパク トを与えているかを肌で感じることができました。 概要 場所: アメリ カ・ ネバダ 州ラスベガス 期間:例年5日間(例年11月下旬〜12月上旬) 参加者数:世界中から6万人以上、日本からは2000人超と現地で聞きました。( SIer や事業会社のIT部門の方など幅広い業界の方々) コンテンツ数:5日間で約3500以上(re:Invent公式サイトのカタログで確認) 参加した主なコンテンツ 1. 基調講演 AWS のCEOをはじめとした幹部陣が、最新サービスの発表や将来的なロードマップを紹介します。 講演前にはバンド演奏などのライブパフォーマンスが行われ、ラスベガスらしい華やかな雰囲気の中で開幕しました。 ※主な新機能についてはこちら ・ https://aws.amazon.com/jp/blogs/news/top-announcements-of-aws-reinvent-2024/ ・ https://www.youtube.com/live/XhUemgp7LHo 2. ブレイクアウト セッション 約1時間の講義形式で進行される専門セッションです。興味のある技術分野を深掘りできます。 こちらは AWS 公式 YouTube チャンネル( AWS Events)に アーカイブ として公開されているためご興味のある方はご覧ください。 AWS Events公式チャネル 3. ワークショップ 2時間程度のハンズオン型セッションです。各自のPCで新機能やサービスを実際に触りながら学びます。 短時間で実践的に習得できるため、普段使わない技術に初めて挑戦する絶好の機会でした。 参加したワークショップの内容を1つピックアップして別の記事でご紹介します。 4. Certification Lounge AWS 認定資格 保有 者向けの専用ラウンジです。 無料の飲食や休憩スペースを利用できるので、会場を走り回る間の良いリフレッシュになりました。 ※右の方は他社の方で掲載の許可は得ています。 5. 5Kマ ラソン 朝早起きして、皆で5キロ走るというシンプルなコンテンツです。 朝食にスムー ジー や果物などの軽食が用意されており、充実した1日をスタートすることができました。 6. ネットワーキング(懇親会) 近畿日本ツーリスト ( AWS re:Inventのパッケージツアー主催会社)の前日懇親会 JapanNight(総勢200名以上が参加されていました) AWS パートナー限定ネットワーキング 普段そもそもリモートで多くの人になかなか出会えない中、多くの他社・他業種の方々との名刺交換、そこからの交流が生まれました。 特に、同世代との出会いは大きな刺激になり、今後のモチベーションにもなりました。 7. GameDay AWS サービスを組み合わせて技術的課題をチームでクリアしつつ、スコアを競うゲーム化された学習イベントです。 参加者同士が少人数のチームを組み、模索しながら実際の AWS サービスを用いてコミュニケーションを取りながら行うのが特徴です。 合計3つに参加し、現地で会った日本人の方や、外国の方に混ざってチームを組んで参加しました。 GameDayとは? 公式引用 3〜4人のチームで与えられた課題をクリアし、スコアを競い合う 手探りで AWS リソースを使いこなしながら、実践的なスキルを身につけられる トラブルを解決するスピード感やチームメンバーとのコミュニケーションが重要になる 参加したGameDay2つ抜粋 実際に参加して感じたこと等 アプリケーションの監視・処理エラー対応、既存 インスタンス タイプからGravitonを使用したタイプへの移行、 アーキテクチャ 見直し等と、多種多様な課題が様々でてきました。 それぞれ得意分野が違うケースもあるため、担当を決めてスタート。後半になると協力しつつ取り組む等チームワークも必要な部分が楽しかったです。 今回現地のGameDayでは Amazon Qという生成AI機能が使用でき、質問するとヒントやエラーの解決手順を、コンソール上のリソースのパラメータを踏まえて提案してくれました。実践的な課題をこなしながら、最新機能にも触れられたのが面白かったです。 チームでスコアを競うため、ゲーム感覚で盛り上がります。学びつつ楽しめるのは魅力でした。 結果は?? 日本人チームとしては、全体で40位台でした。中盤までいいペースだったのですが、後半にスコアが伸び悩み… とはいえ、学びが多くあり非常に充実した時間でした。 外国の方々ともチームを組ませていただいた際は約70チーム中19位とまずまずの結果を残すことができました。 私が1つの項目ををクリアしてcomplete!nice!!ぐらいの会話をしたことを覚えています(笑) AWS GameDayの魅力や学べること スキルの向上 一般的な認定試験や座学では得づらい AWS 上のリアルなトラブルに短時間で向き合うことができます。 自分で考える、時にはチームで協力しながら対応策を練ることで、問題の切り分けや クラウド における実践力が伸びると思います。 GameDayでは横で実際に課題に対処している姿を目にしつつ、時には助言をいただくことができ、特に若手にとっては目で見て学べるいい機会でもあると感じました。 モチベーション 自由度が高い分、なかなか課題が解決できず打ちひしがれる場面もあります。 それでも課題を解決する道筋を考え実際に点数が取れた時の達成感があり、今後もっと経験を積み頑張ろうと前向きになりました。 交流 re:Inventのような大型イベントでは、様々な参加者が集まるため、普段接点がない海外の方や他社のエンジニアと交流するきっかけが生まれます。 技術者同士の情報共有として「こんなトラブルがあった」というリアルな声を聞き合えるのも、GameDayの大きなメリットだと思います。 GameDayまとめ 一言で言えば、 AWS のゲーム化された実践ト レーニン グ です。 認定資格や座学の知識を超えて、実際の クラウド の課題を短時間で体験しながらスキルを養えます。 AWS re:Invent のGameDay に加えて、 AWS Summit等でも開催されることがあるので、特に若手エンジニアの皆さんはぜひ一緒に参加しましょう。 短い時間でも多くの学びと交流、そして新たなモチベーションが得られるはずです。 AWS に注力されている企業さんだと、会社内でチームを組んで出場するというケースもよくあるみたいです。 終わりに AWS re:Invent は、世界規模で AWS の最新情報や技術トレンドを発信する超大規模イベントです。現地に行くと想像を超えた情報量と熱気が待っていました。 新サービスや新機能の発表のみならず、GameDay をはじめとした実践的な学習イベントでの スキルアップ の場、5キロランやre:Playという最後の打ち上げパーティの開催等、一度に様々な体験ができる貴重な場でした。 今後 AWS をはじめとした クラウド 関連の技術を今以上に深めていきたい!といった大きなモチベーションになりました。 個人的には普段の業務での活用はもちろんですが、 Amazon Bedrockや Amazon Qの今後の活用が気になっており、自身で触れたり動向を追ったりしていければなと思っています。 もし AWS に興味を持たれた方は、まずは AWS 認定資格の取得や、毎年日本でも開催される AWS SummitやGameDayへの参加を検討してみてはいかがでしょうか。 AWS Summit2024 私たちは一緒に働いてくれる仲間を募集しています! 株式会社 電通総研 新卒採用サイト 執筆: @miyazaki.hirotoshi 、レビュー: @miyazawa.hibiki ( Shodo で執筆されました )
初めまして。 エンタープライズ 第一本部の1年目の新人、佐藤悠です。 本記事ではやりたいことがない新人やIT企業を志望する学生に向けた AWS 学習のすすめと資格取得の勉強法について紹介する。 目次 なぜAWSを勉強するのか AWSとは 個人レベルでの使用感 Cloud Practionerの取得方法 AWS Cloud Practitionerとは 受験の理由 著者スペック 学習方法 学習教材 テスト当日 まとめ なぜ AWS を勉強するのか ITサービスにはインフラが必ず存在し、インフラの需要はそれに伴って存在する。近年は クラウド 化の潮流もあり クラウド 技術を学ぶこと自体がインフラを理解することに近似してきている。 AWS は クラウド の市場シェアがもっとも高いためニーズある人材になるには AWS を理解することが最短である。やりたいことのない人は来たるときにそれを実現できる力をつけられるという意味でも AWS をやると良いと私は考える。 AWS とは Amazon Web Services の略。 クラウド サービスを提供しておりそのサービスは200種類を超え、多種多様なニーズにこたえることができる。 個人レベルでの使用感 発信する力もエンジニアの力といわれる昨今、私もブログを作成したいと思い、サーバーの立ち上げを試みたが一向にできない。しかし、すでにあるプラットフォームを利用するのはプライドが許さない。そんな時に AWS Lightsailである。様々なテンプレートの中から GUI の操作で好きなものを選び、ブログサーバーが5分でできた。最高である。 このように業務から個人的なものまで大小問わず、さまざまな環境をサクッと作れるのが実感できる良さである。 Cloud Practionerの取得方法 AWS Cloud Practitionerとは AWS の認定資格の1つ。入門資格に位置づけられるが AWS クラウド の基本やサービス、用語を網羅した全体観を知るにはピッタリの資格である。 受験の理由 冒頭に述べた通り。インフラの知識に実務経験があれば飯を食うのに困らなさそうだから。 著者スペック 学部は非情報系 大学院は情報系であるがAIが研究対象なのでインフラの知識はない 新人でインフラの業務は一切していない(取得当時) 基本情報は3か月かけて取得した 記憶力は弱い。インフラのイの字も知らなかった。 学習方法 試験概要 内容 AWS サービスの名称と内容 ベストプ ラク ティスの概念 出題形式 選択肢から1つ正解を選ぶ形式が多数 複数選択が一定数出題される 時間 90分 合格点 7割 一般的には取得のために50時間とするサイトが多いがいらない。 なぜならば選択式だから。 複数選択式は全体割合のうち少数なので、単一選択の4~5択のうち一つを選ぶなら20~25%の確率で正答できる。つまり確実に分かるレベルの知識は過去問に対して半分あればいいのだ。あと合格するかは 正規分布 に従うだろう。 実際に1日1時間を2週間の継続で想定される時間に対し、半分と少しの28時間で合格できた。 学習教材 Udemyで以下の問題集を解いた。 【CLF-C02版】この問題だけで合格可能! AWS 認定 クラウド プ ラク ティショナー 模擬試験問題集(6回分390問) https://www.udemy.com/course/aws-4260 先述の通りこの問題を1周した後、これは確実に正解できると思える問題を50%に引き上げるだけ。2周で十分。 テスト当日 自宅で受験したがこれはおすすめしない。 不正防止のための部屋を整備するのに時間を要した。 ポスターをはがしたり、手の届く範囲にものが存在しない状態にしたりと大変である。 また、受験中に画角から外れることもできないので集中できなかった。 このような手間がかかるので、受験に集中するためにはテストセンターで受験した方がいい。 まとめ CloudPractitionerの受験にあたり効率を重視した手法を紹介したが、これはあくまで全体感をつかむためであり、ここで得た点的知識を 有機 的に紐づけるのは興味を持った分野を自分で触ってみることであったり、資格ベースで進めたい人は次のレベルの取得で検討できたりする。 何よりもやってみることが大事である。試験設計自体がそう言っていると思う。 次回はSolutions Architect Associate取得の勉強方法の記事を書く。 ご覧いただきありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 新卒採用サイト 執筆: @sato.yu 、レビュー: @nakamura.toshihiro ( Shodo で執筆されました )
祝3周年 こんにちは。 X(クロス) イノベーション 本部プロダクト イノベーション センターの中村です。 本テックブログは12月をもって開設3周年を迎えました! 私たちは、この3年間で毎週1本以上の記事を継続的に公開してきました。総数は390本を超え、単純計算で1週あたり2、3本の記事を公開したことになります。手前味噌ではありますが、3年間継続できていることを誇らしく思います。 この記事では、テックブログを継続するために「編集部」が取り組んでいる活動の一端を飾らずに紹介したいと思います。 本記事は、 電通総研 Advent Calendar 2024 の25日目の記事となります。 編集部とは? テックブログ継続のための工夫 レビュープロセス トレンド入りやランキング入りの称賛 アドベントカレンダーの企画 まとめ 編集部とは? 最初に「編集部」について説明します。テックブログの運営には旗振り役の組織が必須です。私たちはその組織を「編集部」と呼び、部門横断で参画希望者を募り現在14人で運営しています。 編集部の活動には、例えば次のようなものがあります。 ブログサービス利用料など各種運営に必要な予算の管理 採用や広報との連携 執筆者へのフィードバックとサポート 編集部の人員入れ替えを意図的に実施することで多くの方に編集部に関わってもらう工夫もしています。これにより、新しい視点やア イデア を取り入れ、継続的な改善の促進を狙っています。 テックブログ継続のための工夫 以下、テックブログを継続するために実施している3つの工夫を紹介します。 レビュープロセス 記事のレビューは編集部と広報担当部署が中心となって実施します。私たちはレビューに Shodo というツールを活用しレビュー効率を高めています。Shodoは誤字脱字や表記ゆれなどを自動検出してくれるため、レビュアーは本質的な部分に集中してレビューが可能です。基本的には執筆者の意思を尊重したいので、レビューアーは、「非開示情報が含まれていないことの確認」や「より多くの人に読まれるための助言」といったフィードバックを中心に行います。 また、あらかじめ「質より量」や「等身大の自分たちを表現する」といったポリシーを定めているため、記事の品質や技術的な優劣を問題にしてレビューが紛糾することはありません。 ツールの活用と事前に定めたポリシーの存在がレビューの負荷低減に繋がっています。レビューでレビューアーとレビューイーの双方が消耗しないことは重要なポイントだと考えています。 トレンド入りやランキング入りの称賛 執筆記事が はてなの企業技術ブログのトレンド や何らかのランキングに掲載された際は、執筆者コミュニティ内で共有と称賛を行っています。トレンド入りを目標にしているわけではないのですが、多くの方に注目されたということの証左の一つだと思いますので、素直に「素晴らしい!」という想いを皆で共有しています。 ささやかなものではありますが、称賛を表明する機会や場は、モチベーションの向上にポジティブな効果があると感じます。 アドベントカレンダー の企画 12月は毎回 アドベントカレンダー (25日まで毎日記事を公開する企画)を実施しています。今回を含めてこれまで4回実施していますが、いずれも執筆者募集から数日で応募枠が埋まるほどの人気ぶりです。 アドベントカレンダー は編集部からすると少し負荷が掛かる取り組みではありますが、年に1度くらいであれば日常のスパイスとなって皆で楽しめますし、テックブログ参加者の活気を維持するのに役立ちます。 多くの アドベントカレンダー では、12月1日から25日まで休みなく継続することが多いと思いますが、私たちは土日祝日を休むという選択をしています。休みの日に無理して執筆する・公開するほどまでに頑張らなくてもいいよね、というスタンスです。しっかり休むことで執筆者と編集部の負担を軽くしています。 多くの人が無理なく一緒に盛り上がれるようなイベントを定期的に行うことは、テックブログのような活動を続ける上で大切だと考えています。次のイベントに向かってまた頑張ろうという活力が生まれやすくなるからです。 アドベントカレンダー は来年も継続できればと考えています。 まとめ テックブログを継続するためには、いくつかの重要なポイントがあります。 まず、無理をしないこと。私たちは、執筆者が無理なく記事を書ける環境やポリシーを整えることを大切にしています。また、執筆者だけでなく編集部も無理なく運営に携われることを常に意識しています。 次に、執筆者へのフィードバックや称賛も重要です。公開前に適度なレビューを行うことで「この情報を公開して良いのだろうか?」といった不安は除去されますし、称賛により努力が認められればモチベーションの向上に繋がります。 さらに、 アドベントカレンダー のようなイベントを楽しむことも大事にしています。ちょっとしたことではありますが、皆でワイワイと記事が途切れないように協力するのは面白いだけでなく一体感を生む良い機会にもなります。 私たちは今後も週に1本以上の記事の公開を目標に活動を続けていきます。引き続き、本テックブログをよろしくお願いします! 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆: @nakamura.toshihiro ( Shodo で執筆されました )
皆さんMerry Christmas!コーポレート本部 サイバーセキュリティ推進部 セキュアシステムデザイングループの福山です。 本記事は、 電通総研 Advent Calendar 2024 の24日目の記事となります。 今回は、私の好きな AWS サービスの一つである Amazon Detectiveについてお届けしたいと思います。 はじめに Amazon Detectiveとは Detectiveを有効化してみよう! 管理アカウントでの作業 メンバーアカウントでの作業 GuardDutyアラートの生成 Detective管理アカウントによる調査方法 検出結果グループ(finding groups) 調査機能(Detective Investigation) IAMユーザーを調査 ロールを調査 検索機能(search) アカウントIDで検索 インスタンスIDで検索 インスタンスに紐づくロールで検索 IPアドレスで検索 IAMユーザー名で検索 まとめ 最後にちょっとだけ補足 はじめに AWS 上で発生した セキュリティインシデント を調査する際、GuardDuty の検出結果、CloudTrailや VPC フローログ等を読み解く作業が発生します。 しかし、これらのログ調査には知見と労力が必要です。 そんな課題を解決し得るサービスが AWS には存在します。 Amazon Detectiveとは Amazon Detectiveは、 AWS 上で発生した セキュリティインシデント の調査を容易にするサービスです。 CloudTrail/ VPC フローログ/GuardDutyの検出結果などのログデータを自動で収集し、"動作グラフ"と呼ばれる各アカウントに紐づくデー タセット を生成し、 機械学習 ・統計分析を用いて可視化します。 下図は セキュリティインシデント の調査のプロセスを示しています。 Detectiveを使わない従来の調査方法では、それぞれのプロセスで利用するサービスが異なるため、時間と手間が発生していました。 Detectiveを使うことで、各サービスのログがDetectiveに集約・分析され、 セキュリティインシデント の調査を 一気通貫 で進めることができます。 引用: https://www.youtube.com/watch?v=Vf-s3ZQmJhc Detectiveを有効化してみよう! と言いたいところですが、その前に重要なポイントがあります。 それは、Detectiveでは マルチアカウント連携が可能 であるということです。 例えば、複数の AWS アカウントを抱える組織のSOCやCSIRTが、Detective管理アカウント(ログの集約アカウント)を使って、メンバーアカウント(ログを吐くアカウント)で起きた セキュリティインシデント を調査する、といった構成を組むことができます。 詳細は下記のユーザーガイドを確認してください。 https://docs.aws.amazon.com/ja_jp/detective/latest/userguide/accounts.html 以降の説明では、マルチアカウント連携を行う前提で進めます。 管理アカウントでの作業 まずはDetective管理アカウントとなるアカウントでDetectiveを有効化しましょう。 必要に応じてオプションデータソースを有効化します。 " AWS セキュリティ検出結果"を有効にすると、メンバーアカウントのSecurity Hubの検出結果を収集することが可能です。 メンバーアカウントでEKSを利用している場合はEKS監査ログも収集できますが、ログのデータ量によってはメンバーアカウント側に想定外の課金が生じるため注意してください。 30日間の無料期間がありますので、その間に費用感をチェックすることをお勧めします。 各アカウントを招待しましょう。DetectiveはOrganizations連携にも対応しています。 組織アカウントを Detective メンバーアカウントとして有効にする 個々のアカウントを動作グラフに招待する メンバーアカウントでの作業 メンバーアカウント側で設定すべき内容は以下です。 GuardDutyの有効化(必須) Detectiveに取り込まれるためには、GuardDuty有効化後、48時間が経過している必要があります。 GuardDutyの検出結果のエクスポートオプション で更新結果の取り込み頻度を15分に変更する(推奨) デフォルトは6時間になっており、GuardDutyの更新結果がDetectiveに反映されるまでに時間がかかります。 15分に設定することをお勧めします。 招待を承諾 (マルチアカウント連携の場合は必須) 招待を承諾してから、管理アカウントが情報を取り込むまでに最大24時間を要します。 メンバーアカウント側で事前にDetectiveを有効化してしまうと、メンバーアカウントの動作グラフが管理アカウント内およびメンバーアカウント自身に存在するため、それぞれに課金が発生します。 メンバーアカウント側でDetectiveを使って調査する必要がなければ、メンバーアカウントでDetectiveを明示的に有効化する必要はありません。 アカウント連携前のログはDetectiveに取り込まれません。 Security Hubの有効化(必要に応じて) Inspectorの有効化(必要に応じて) GuardDutyアラートの生成 続いて AWS 上にリソースを立てて、擬似攻撃を起こしてGuardDutyアラートを生成しましょう。 今回は、コマンド1つでサンプルではない実際のGuardDutyアラートを生成できるツール"GuardDuty Findings Tester"を用います。 https://github.com/awslabs/amazon-guardduty-tester GuardDuty Findings Testerでは、攻撃元となるリソース(Kali Linux )と、攻撃対象となるリソースをCDKでデプロイします。 アラート生成方法としては、FindingType指定をはじめ、リソース種類別、ログソース別、MITRE ATT&CKの Tactics (攻撃戦術)別などがあります。 今回は下記のFindingTypeを指定して検出させてみました。 UnauthorizedAccess:EC2/RDPBruteForce UnauthorizedAccess:EC2/SSHBruteForce なお、以下の点は予め留意した上で、デプロイ先のアカウント、GuardDutyの通知先を事前に考慮することをお勧めします。 本環境はTorノードにアクセスする仕様になっているため、CDKをデプロイした後にUnauthorizedAccess:EC2/TorClientが勝手に検出される FindingTypeを指定して検出させても、複数のアラートが発生する場合がある Detective管理アカウントによる調査方法 お待たせしました。Detectiveを使って調査を始めましょう! Detectiveで利用できる機能は大きく分けて3つあります。 検出結果グループ(finding groups) 関連性のありそうな検出結果を検出結果グループとしてまとめてくれる機能です。 検出結果グループの概要を要約してくれたり、各エンティティ間の関連性を可視化してくれます。 注意点として、GuardDutyアラートが生成されて検出結果グループが作成されるのに最大48時間を要するということ、 利用できるリージョン に限りがあります。 検出結果グループの一覧 検出結果グループの概要を要約 生成AIによって個々の検出結果グループを要約する機能で、以下のような内容を確認できる i-0dc6330b23830eb27は、ポートスキャン、他のIPに対する SSH /RDP ブルートフォース攻撃 、Torとの通信を実行した。 また、悪意のある IPアドレス から API コールを行った。 i-010e2e28e9486f520はポートスキャンと SSH ブルートフォース アタックを実行した。 この インスタンス では悪意のあるファイルも検出された。 172.16.0.169は、i-0dc6330b23830eb27とi-010e2e28e9486f520からのポートスキャンと SSH ブルートフォース アタックの標的となった。 関連する以下の検出結果を一覧で確認できる GuardDuty Security Hub Inspector(ネットワーク到達可能性とソフトウェアの 脆弱性 ) 各エンティティ間の関連性を可視化(Finding group visualization) 攻撃の起点や関連しているリソースを図から読み取れる ブルートフォース 系のアラートはインバウンド/アウトバウンドで色分けされる Finding group visualizationから特定のエンティティを選択してドリルダウン的に検索することが可能(→ インスタンスIDで検索 に遷移) 調査機能(Detective Investigation) IAMユーザーまたはロールに関連する IoC (Indicator of Compromise; 侵害の証跡)を調査し、レポートを作成します。 対象のIAMユーザーまたはロールが セキュリティインシデント に関与しているかの判断に役立つ機能です。 リソース(IAMユーザーまたはロール)を選択し、調査を実行するとレポートが生成され、影響度に基づいて調査結果の重要度が割り当てられる IAMユーザーを調査 MITRE ATT&CKのTTP(攻撃手順)によって マッピング され、重要度が判定された例 ロールを調査 重要度が高いアクティビティがある IPが表示され、関連するGuardDuty検出結果が表示された例 IPアドレス でドリルダウンしたい場合は IPアドレス のリンクをクリック(→ IPアドレスで検索 に遷移) 検索機能(search) アカウントレベル、またはアカウント内の各エンティティレベルで分析できる機能です。 いくつか例をあげてみました。 アカウントIDで検索 GuardDuty、Security Hub、Inspectorの検出結果を一覧で確認できる(各エンティティレベルでも確認可能) 新しい動作では、新たに観測された位置情報を確認できる(各エンティティレベルでも確認可能) 時間範囲内に観測された位置情報はオレンジの丸で表示される 位置情報を一覧でも表示でき、全体の API 呼び出しに占める割合なども確認できる インスタンス IDで検索 対象 インスタンス の詳細(作成者や作成時刻など)を確認できる ロールをドリルダウンしたい場合はロール名のリンクをクリック(→ インスタンスに紐づくロールで検索 に遷移) インスタンス に紐づく IPアドレス を確認できる VPC フローログに基づいて観測されたリモートの IPアドレス を一覧で確認できる リモートの IPアドレス の通信の方向、allow/denyについてフィルターできる インスタンス に紐づくロールで検索 検出結果グループや調査レポートとの紐付けがあれば確認できる 調査(Detective Investigation)が未実施であればその場で実施できる(→ ロールを調査 に遷移) IPアドレス 別 -> サービス別の API の呼び出し結果を一覧で確認できる IPアドレス で検索 IPアドレス の詳細を表示。逆引きが出力されたりはしない(3.x.x.xなので AWS という想像はつきますが)。 リソースとのインタ ラク ションを確認できる IAMユーザー名で検索 検出結果グループや調査レポートとの紐付けがあれば確認できる 調査(Detective Investigation)が未実施であればその場で実施できる(→ IAMユーザーを調査 に遷移) 対象のIAMユーザーによって呼び出されたサービス別の API の結果を一覧で確認できる(キャプチャは割愛) まとめ Detectiveを活用することで、 セキュリティインシデント に関連したリソースが可視化され、調査が容易になります。 以下のポイントを押さえ、効果的な活用を目指しましょう。 Detective管理アカウント/メンバーアカウントにて事前に必要な設定を実施する。 Detectiveの各種機能を活用 検出結果グループ: 複数のセキュリティイベントの関連性を俯瞰的に把握する。 調査機能: IAMユーザーやリソース単位での分析を行い、侵害の痕跡( IoC )を特定し、 セキュリティインシデント への関与を判断する。 検索機能: エンティティレベルで詳細に分析できるようになっており、問題の根本原因を特定する。 コストへの配慮 Detectiveの利用においては、30日間の無料期間中にデータ量や費用感を確認する。 メンバーアカウント側で予め明示的にDetectiveを有効化しないこと。 オプションデータソースであるEKS監査ログは必要なければ有効化しないこと。 最後にちょっとだけ補足 Detectiveの使い方としては、検出結果グループで概要を掴み、その後は調査機能でインシデントの有無を判断したり、検索機能で詳細調査する流れが理想的かと考えています。 ただし、検出結果グループが反映されるまでにGuardDutyアラート生成後、最大48時間を要するという制約があり、検出結果グループを見たい時にまだ見られないということが起こり得ます。 上記について改善要望を挙げていますが、より早く検出結果グループが生成されるように改修されることを期待したいと思います。 また、Detectiveがその効果を最も発揮するのは、 Amazon Detectiveとは で図示されている通り、Inspector、Security Hub、GuardDutyの検出結果から、それぞれの関連性を読み解く必要性が生じた時だと思います。 例えば、利用している OSS にSSRFの 脆弱性 があり、 インスタンス IMDS v2が適用されておらず、GuardDutyから"UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS"が検出された。みたいなケースです。 参考: https://aws.amazon.com/jp/blogs/news/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/ 今回利用したGuardDuty Findings Testerではそのようなシナリオを作ることが難しいため、あくまで機能紹介という形でお伝えしました。 私たちは一緒に働いてくれる仲間を募集しています! 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆: @fukuyama.kenta 、レビュー: @nagamatsu.yuji ( Shodo で執筆されました )