コーディングエージェントを使ってみて思うこと
はじめに
メーカーのコーポレート部門でテックリードをしているmongolyyです。
よく語られるテーマではありますが、最近コーディングエージェントを使って感じたことをいくつか書き留めておきます。
その1: 集中力が切れかかっているときもプログラムが書けるし、裏を返すとやりすぎてしまう
手でコードを書いていた頃は、稀に遭遇する問題（CJSとESMの互換性によるビルドエラーなど）にぶつかると、かなりの集中力を要しました。 そのため、集中力が落ちてくる夜にはやりきれないことが多かったです。しかし、コーディングエージェントによってこの状況は変わりました。今はそこまで集中しなくてもコードが書けてしまいます。
これは良くも悪くもで、集中力が切れかかっている状況でも仕事を続けられる一方、自分が限界に達しているのに気づかずコーディングを続けてしまうことがあります。
日々の体調管理（睡眠時間、適度な運動など）や息抜きが重要だと感じます。
その2: 品質の問題
これは両面があります。コーディングに集中しすぎない分、視野が広がり、チェックできる箇所が増えました。また、ちょっとした技術課題を解消するハードルも下がりました。その結果、品質は上がると感じます。
一方で、本人の特性が色濃く出る側面もあります。十分にチェックせずレビュー依頼を出してくるケースも見られます。つまり、全体の水準が上がるというより、各自が出せるアウトプットの速度が高速になるイメージです。
そのため、設計段階でしっかり対話することが重要です。コーディングエージェントを使うと大きなプルリクエストを作りやすく、実際に作りがちです。だからこそ設計が最も重要になります。
コーディングエージェントは設計の壁打ちもできます。モブやペアでエージェントと設計の壁打ちをし、それをもとに開発すれば手戻りを減らせると考えています。
おわりに
今回は、開発をやれすぎてしまう問題と品質の問題について書きました。
各所で言われていることですが、自分のスキルや特性が反映されたものが高速で作られる時代になってきています。改めて自分のスキルを磨く必要性を感じる今日このごろです。
「AWS Certified Solutions Architect - Associate」合格体験記
はじめに
メーカーのコーポレート部門でテックリードをしているmongolyyです。
今回、「AWS Certified Solutions Architect - Associate」を受験し、無事合格しましたので、その体験記をまとめます。
どんな勉強を、どのくらいした？
まずは、試験ガイド をざっと確認しました。内容的に特に不安はなかったため、すぐに問題集に取り組むことにしました。
活用したのは、Ping-tさん（教材 | Ping-t）です。 当時は、本試験向け問題集が無償で利用できたので、それをメインに学習しました。
- 問題数：808問（非常に多い！）
- 実際に解いた数：150問程度（途中で「これなら大丈夫そう」という手応えがあったため）
- 学習方法：スマホで通勤時間に解くスタイル。マルチデバイス対応で、途中から再開できるのも便利でした。
- 学習期間：約1週間
- 学習時間：合計2〜3時間程度
結果はどうだった？
無事合格してました！
ちょっと前ですが、AWSのSolutions Architect Associateも合格してました！
— モンゴル (@mongolyy) 2025年8月12日
思った以上に難しかった！ pic.twitter.com/NqeNHP7vk1
合格ラインは 720点 / 1000点 ですが、私は 827点 で、少し余裕を持って合格できました。
おわりに
全体的に ベーシックな問題が多く、AWSを幅広く学びたい人におすすめ できる試験だと感じました。
Professional や Specialty 試験は、特定サービスに関する深い理解を求められる問題が多いですが、この試験はサービスの幅広い知識を問われる印象です。
また、試験問題については、全体的に Ping-t さんの問題集よりもやや難しい印象を受けました。
ただし、Ping-t さんの問題集をしっかり理解していれば十分対応できるレベルだとも感じています。
特に実務でAWSに触れている方であれば、この問題集に取り組むことで合格ラインには到達できると思います。
「AWS Certified Advanced Networking - Specialty」合格体験記
はじめに
メーカーのコーポレート部門でテックリードをしているmongolyyです。
今回、「AWS Certified Advanced Networking - Specialty」を受験し、無事合格したので、体験記を書いていこうと思います。
なんで取ろうとした？
AWS認定全制覇をするためです。
昨年にre:Inventに行ったことをきっかけに、もっと詳しくなり、かつ、残せるものもあるといいなと思っており、その一つとしてAWS認定全制覇を目指していました。
Specialty試験は既に、「AWS Certified Machine Learning - Specialty」と「AWS Certified Advanced Networking - Specialty」を保持していました。
なので、本試験が最後のSpecialty試験となります。
どんな勉強を、どのくらいした？
試験ガイド を読んで、オンプレとAWSのネットワーク接続については、ほとんど理解できていないことに気づきました。
したがって、AWS Blackbeltで基礎を固めました。
その後、試験問題になれるために、Udemyの模擬試験にも取り組みました。
こちらは回答の解説に図があり、理解しやすかったです。
また、単なる点数チェックではなく、間違った問題はググったり、ChatGPTに聞いたりしながら調べ、理解することを意識しました。
勉強時間ですが、Youtubeで2時間、Udemyで6時間くらいで、合計8時間くらいだったと思います。
結果はどうだった？
ギリギリ合格してました！
週末に受験した「AWS Certified Advanced Networking - Specialty」に合格してた！ pic.twitter.com/1YfpdI2psl
— モンゴル (@mongolyy) 2025年7月22日
750点/1000点で合格のところ、770点だったので、またもやギリギリでしたね（笑）
おわりに
最難関、と言われることもありますが、AWSサービスというよりもネットワークに関する知識が前提となっている問題が多くあるので、確かになーと思いながら受験していました。
幸い、私はネットワークスペシャリスト試験の受験 & 合格の経験があったのでその知識で対応できました。
ネットワークの知識に自信のない方は以下の書籍を軽く読んで、基礎概念を押さえてから受験するとスムーズかと思います！
期限切れも含みます（汗）が、全制覇まで残る試験は5つ！
今年中に取りきるぞ！
「Tidy First?」を読んだ
はじめに
メーカーのコーポレート部門でテックリードをしている mongolyy です。
友人と気になるよね、と、「Tidy First?」を一気に読んだので感想を書いていこうと思います。
感想
「いつ、どのくらい整頓（≒小さいリファクタリング）するか？」を言語化できるようになる
結局は、「リファクタリングのコスト」+「そのあとのふるまいの変更のコスト」が、「リファクタリングなしのふるまいの変更のコスト」と比べて大きいかどうかで判断するということで理解しました。
面白いのは、ほぼ同じであれば、リファクタリングは後にした方がいいという点です。 顧客に早く価値提供できるので、リファクタリングせずに実装し、あとからリファクタリングした方が提供価値は大きいと理解しました。
やみくもにリファクタリングすべきでない、すぐにリファクタリングしなくていいというのを言及している本に出会ったことはなかったので、新鮮でした。
整頓のプルリクエストのレビューについて見直す機会となった
本書では、整頓のプルリクエストはレビューアーをなくしてもいいかもしれないと書いてありました。
整頓のプルリクエストについて、レビューアーはもっと少なくしてもよさそうだなという認識になりました。
そうすることで、プルリクエストのレビューのオーバーヘッドは減り、スピードも上がり、ふるまいの変更と整頓のプルリクエストを分けるモチベーションが生まれるので、非常にいいなと思いました。
おわりに
120ページほどで、薄い本だったので半日くらいで読み終わりました。
このくらいだと、だれずに一気に読めるのでいいですね。
「リーダブルコード」や「リファクタリング 第2版」を読んでいる場合は、かぶる部分もあるので、第三部だけを読むのもおすすめです。
自然とやっていることかもしれませんが、「いつ、どのくらいリファクタリングするか？」ということを強く意識、言語化できるようになると思います
「AWS Certified Machine Learning Engineer - Associate」合格体験記
はじめに
メーカーのコーポレート部門でテックリードをしているmongolyyです。
今回、「AWS Certified Machine Learning Engineer - Associate」に合格したので、体験記を書いていこうと思います。
なんで取ろうとした？
今年のre:Inventに参加させていただくことになり、せっかくだから何かやってみようと思ったのがきっかけです。
また、自分自身SageMekerのことをあまり知らなかったので、この試験勉強を通して、基本的な部分をおさえたいという考えもありました。
どんな勉強を、どのくらいした？
試験ガイド を読んで、Amazon SageMakerの知識が必要だと感じました。
ほんのわずか触ったことがある程度で、基礎から学ぶ必要性を感じたのでAWS Skill Builderで勉強しました。
タイトルに「AWS ML Engineer Associate」という文言が含まれていて、特にわからなそうなやつを中心に4つの講座を受講しました。
日本語版があったので学びやすかったです。
今回受けた講座はサブスク（29USD/月）契約が必要なものでしたが、その価値はあると思いました。
Skill Builderで他のML系講座を受講しながら、実際にSageMekerを触って理解を深めました。
また、私にとって定番ですが、試験問題に慣れるために、Udemyの模擬試験もやりました。
こちらも有償ですが、非常に効果はあったと思います。
また、Udemyでアップデートがあったようで、それによってめっちゃ勉強しやすくなってました。
Udemyのupdateで追加された演習モードめっちゃええやん
— モンゴル (@mongolyy) 2024年12月17日
これ欲しかったやつhttps://t.co/7eCIvfmI4G
勉強時間ですが、
Skill Builderで4時間、Udemyで4時間くらいで8時間くらいだったと思います。
結果はどうだった？
ギリギリ合格しました！
re:Inventに行く前の景気づけとして、「AWS Certified Machine Learning Engineer - Associate」取得したった！ pic.twitter.com/odoukrCV3E
— モンゴル (@mongolyy) 2024年11月25日
おわりに
re:Invent行く前に、せっかくだから何か取ろうと思ってチャレンジしてみましたが無事とれてよかったです！
MLのパイプライン構築や運用が理解できたのが良かったです。
もうちょっと勉強して、来年はMachine Learning Specialityを取りたいと思います！
「脳に収まるコードの書き方」を読んだ
はじめに
メーカーのコーポレート部門でテックリードをしているmongolyyです。
書店に立ち寄った時に気になって買った本を読みました。
気づきを書いていきます。
気づき
認知負荷を低くするための考え方
本書で、人間の思考モードが二つあるということを知りました。
何も意識しないと一つ目の思考モード（すぐに答えに結び付けようとしてしまう）が優先され、誤解したり、理解できないコードだと感じてしまうという話がすごく共感できました。
つまりぱっと見の「ん？」「あれ？」をいかに起こさないかというのが重要だと理解できました。
そう考えると、コメントには「判断の結果」よりも、「なぜそう判断したか」を書くというのは納得できる考え方だと思いました。
また、「7つ以上のことを入れない」というのも、ワーキングメモリーに基づき「ん？」「あれ？」を生まないためのキーワードだなと感じました。
今までは「同じようなif文であれば別にいいかな」と思っていましたが、安直にそうせず、高レベル、低レベルの実装に分割できないか考えるようにしたいと思います。
メソッドの設計について、「メソッド名を隠して、クラス名やシグニチャだけでそのメソッドが何をやっているかわかるか」という問いで、いい設計か判断するというのも興味深かったです。
メソッド名だけでなく、シグニチャに拘っていきたいし、シグニチャが微妙である場合はそのクラスであるべきか疑った方がいい兆候として考えていこうと思います。
コミットメッセージでさえも、チーム開発を意識する！
コミットメッセージやコードレビューでは、「書く、指摘する」ということではなく、「読み手とコミュニケーションする」というのが大事だということが理解できました。
コードレビューはまだしも、コミットメッセージもコミュニケーションを意識するというのは考えたことがなかったですが、確かにできるプログラマーはコミットメッセージも手を抜かないし、わかりやすいなと納得しました。
開発は一人だけでやっているわけではないので、いろんなポイントで人に伝えようとする、人の意見を引き出そうとするふるまいがいいプロダクトを作るんだなと思いました。
コミュニケーションを通して、暗黙知から形式知を生み出したり、複数の案を比較検討することでより良い解決策を見出すことができるんだもんな、と再認識できました。
「チーム開発の営みはどこまでもできる！それをきわめて、より良い設計を見出すべし」と学びになりました
おわりに
コードを書く技術だけでなく、ソフトウェア開発、チーム開発における哲学を考えさせられる一冊でした。
個人的には7~9章が激アツでした。
また、コードレビューに関する以下の観点もすごくいいなと思いました。
Things I think about during a code review:
— Cory House (@housecor) 2019年4月10日
Is the intent clear?
Is there needless duplication?
Could existing code have solved this?
Is this an atomic commit?
Could this be simpler?
Are there logic issues?
Does this follow our standards?
Are the tests comprehensive and clear?
本書に書いてあったことの受け売りですが、今後は「自分はこれのメンテナンスを問題なく行えるか？」という観点でレビューしていこうと思います。
「Amazon Bedrock 生成AIアプリ開発入門 」を読んだ
はじめに
メーカーのコーポレート部門でテックリードをしているmongolyyです。
最近Bedrockを使うことがあったのですが、その場その場で使っていたこともあり、もうちょっと網羅的に学びたいという思いがありました。
そんな時に本書が出版されていたのでやってみました。
気づき
基礎知識としての、生成AIアプリの説明が非常に丁寧で勉強になった
以下のような事柄は割とざっくりした理解だったので、非常に助かりました
- プロンプトエンジニアリング
- ドキュメントの付加情報について、XMLで書ける
- 長いドキュメントをプロンプトに含める場合は、質問や指示は最後に記述するとよい
- 埋め込み
- チャンクとは？
- セマンティック検索とベクトル検索の違い
- Kendraもセマンティック検索はできるが、ベクトル検索とどう違うか？
- Knowledge bases for Amazon Bedrock を使うと何がうれしいのか？
業務利用を想定して、迷いそうなところの解説が多くあって早速役に立った
以下のような部分について解説があり、業務で役立ちました
筆者の考えが入っており、AWSの公式ドキュメントでは突っ込まれなそうなところまで書いてあって良かったです
- AWSのリージョンの選び方について
- リージョンの選定についてのトレードオフやどちらでもいい場合の選定の考え方が書いてありました
- Bedrockのモデル選定について
- テキスト生成、埋め込み、画像生成という観点で各モデルの特徴がわかりやすく解説されており、迷った場合のおすすめが解説されていました
- いままではとりあえずClaude3, 3.5使っておけばいいんでしょ？くらいの認識だったので、他のモデルに関しても状況がしれたり、埋め込みや画像生成だと違うモデルを使うとか基本的な部分の理解も進みました
- Cludeのパラメータの調整のやり方
- おすすめのRAGアーキテクチャの例
- pineconeを使う話など
- カスタムモデルの作り方
- 本書を読むまではファインチューニングしか知らなかったのと、具体的なイメージはあまりなかったので勉強になりました
新しいサービスを色々知った
タイトルとしてはBedrockとなっていますが、Bedrockと組み合わせて使えるライブラリやサービスがいろいろ紹介されていました 特に、以下は今後も使ってみたいなーと思いました
- streamlit
- https://streamlit.io/
- UIのコードを詳細に書かなくても、数行宣言的に書くだけでいい感じにデザインを生成してくれるライブラリ
- 本書でも多用されていましたが、PoCで重宝しそうだと感じました
- 「Dify」や「Bedrock Studio」の採用などにより、これすらも不要になるかもしれませんが、LangChainやPrompt Flowと組み合わせたときに有用そうに感じました
- PartyRock
- https://partyrock.aws/
- 自然言語だけで生成AIのアプリが作れるので、よりカジュアルなアプリをPoCで作りたい場合はこれを使うとよさそうだと思いました
ハンズオンが充実
普段はzennの記事などを読みながら、触りしかやらないことも多かったのですが、本書にはがっつり説明があってよかったです。
また、AWSコンソール上での操作説明が詳細に記述されており、非常に助かりました。
一方、私が購入したkindle版の場合は書籍内のテキストがコピーできず、そこが不便でした。
ただ、本書のサンプルコードがgithub上で公開されているので大きな問題にはなりませんでした。
個人的には、Knowledge bases for Amazon Bedrockは触りしかやったことがなく、こういう設定ができるんだーという学びがあってよかったです。
おわりに
非常に良かったです。
前半（1~3章）を読んだら自分の興味関心部分だけやるとかもありだと思います。
本書が非常にわかりやすかったのと、最近のアップデートにより、LangChainすら使わずに、「Amazon Bedrock StudioやPrompt Flowsが使う」ケースや、「自前でDifyの環境を立ち上げる」ケースが増えてきそうだとも考えており、そういった内容が書かれた、増補版？別の書籍？が出ないかなーと期待しているお気持ちです。
