[{"content":"Claude Codeの作者であるBoris氏が、自身のClaude Code活用法をX（旧Twitter）で共有していた。これが非常に参考になったので、翻訳と所感をまとめてみる。\nI\u0026#39;m Boris and I created Claude Code. Lots of people have asked how I use Claude Code, so I wanted to show off my setup a bit.\nMy setup might be surprisingly vanilla! Claude Code works great out of the box, so I personally don\u0026#39;t customize it much. There is no one correct way to…\n\u0026mdash; Boris Cherny (@bcherny) January 2, 2026 導入：意外とバニラな使い方 僕はBorisで、Claude Codeを作りました。たくさんの人から「どうやってClaude Codeを使ってるの？」と聞かれるので、僕のセットアップを少し紹介したいと思います。\n僕のセットアップは意外とバニラ（素のまま）かもしれません！Claude Codeは箱から出してすぐ（out of the box）でも十分うまく動くので、僕自身はあまりカスタマイズしていません。Claude Codeに「正しい使い方」は一つもありません。僕たちは意図的に、あなたが好きなように使い、カスタマイズし、ハックできるように作っています。Claude Codeチームの各メンバーも、それぞれまったく違う使い方をしています。\n作った本人が「あんまりカスタマイズしてない」と言っているのは個人的にかなり助かる。あまりにも進化が早すぎて一時的なカスタマイズをしないと最大限のパフォーマンスが引き出せないのは辛い。\n1. ターミナルで5つのClaudeを並列実行 ターミナルで5つのClaudeを並列で動かしています。タブに1〜5の番号を振って、Claudeが入力を必要としているときはシステム通知で知らせてもらっています。\n所感: 並列で5つ動かしているのは凄い。正直、Proプラン契約をしているのも相まってそこまで並列で流せていないのは実情。Opus 4.5だとすぐ5時間の制限にひっかかるので、中々厳しい。\n参考: iTerm2 システム通知設定\n2. Web版 + モバイルとの連携 ローカルのClaudeと並行して、claude.ai/code でも5〜10個のClaudeを動かしています。ターミナルでコーディングしながら、ローカルのセッションをWeb版に渡したり（\u0026amp;を使って）、Chromeで手動でセッションを立ち上げたり、時には --teleport で行ったり来たりもします。毎朝、そして一日を通してiPhoneのClaudeアプリからもいくつかセッションを開始して、後でチェックしています。\n補足:\nclaude.ai/code: ブラウザからGitHubリポジトリに直接接続して作業できるWeb版Claude Code。Pro/Max/Team/Enterpriseプラン向け \u0026amp; キー: ローカルセッションをWeb版に引き継ぐ teleport: 公式ドキュメントに明記なし。類似機能として claude --resume や claude --continue がある 所感: うーん物凄い運用してる。朝起きたらスマホからタスクを投げて、パソコンの前に座ったら結果を見る、という非同期ワークフローは理想的だとは思うけど、そこまでやるのも凄いな。\n3. Opus 4.5 with thinking を使う理由 すべての作業にOpus 4.5（thinkingモード）を使っています。今まで使った中で最高のコーディングモデルです。Sonnetより大きくて遅いけれど、指示を細かく出す必要が少なく、ツールの使い方も上手なので、結局は小さいモデルを使うよりほぼ常に速く終わります。\n所感: 実際、Opus 4.5を使うのが最適に感じる。Sonnetだと中途半端に手戻りする感覚はある。\n4. CLAUDE.mdをチームでgit管理 私たちのチームはClaude Codeリポジトリで1つのCLAUDE.mdを共有しています。gitにチェックインしていて、チーム全員が週に何度も貢献しています。Claudeが何か間違ったことをするたびにCLAUDE.mdに追記して、次回は同じことをしないようにしています。\n所感: CLAUDE.mdの管理は必須だよね。どこまで何書くかだよなぁとは。\n5. PRに@.claudeでコメント コードレビュー中、同僚のPRに@.claudeをタグ付けして、そのPRの一部としてCLAUDE.mdに何かを追加してもらうことがよくあります。これにはClaude CodeのGitHubアクション（/install-github-action）を使っています。これはDan Shipper氏の「Compounding Engineering（複利エンジニアリング）」の私たちなりのやり方です。\n所感: これはやりたい機能。個人的にはCLIベースでやりたいし、パブリックリポジトリにはCLAUDE.mdを置きたくない事情もあるので今は見送っているが、チーム開発なら必須だと思う。\n補足: 「複利エンジニアリング」とは、知識やドキュメントを積み重ねることで、複利のように効果が増えていくという考え方。\n6. Planモードから始める ほとんどのセッションはPlanモード（Shift+Tab を2回）から始めます。プルリクエストを書くことが目標なら、Planモードを使って、計画が気に入るまでClaudeと何度もやり取りします。そこから編集の自動承認モードに切り替えると、Claudeは大抵1発で仕上げてくれます。良い計画は本当に重要です！\n所感: Planモードは最近使ってみて、とても良い仕組みだと感じた。計画をしっかり立てたら、あとは一気に実装できる。今後も何か作るときは積極的に使いたい。\n操作: Shift+Tab を2回押すとPlanモードに入る\n7. スラッシュコマンドで定型作業を自動化 1日に何度も行う「インナーループ」のワークフローには、すべてスラッシュコマンドを使っています。これで繰り返しプロンプトを打つ手間が省けるし、Claudeもこれらのワークフローを使えるようになります。コマンドはgitにチェックインされ、.claude/commands/ に置いてあります。\n例えば、Claudeと私は /commit-push-pr というスラッシュコマンドを毎日何十回も使います。\n補足:\n作成場所: .claude/commands/（プロジェクト共有）または ~/.claude/commands/（個人用） 例: .claude/commands/security-check.md を作成 → /security-check で呼び出せる 登録すべきもの: 毎日何度もやる作業、定型的なレビュー依頼、テスト実行手順など 所感: スラッシュコマンドの存在は知っているが、何を登録すべきか悩んでいた。「インナーループ」（開発中に何度も繰り返す作業）を意識して、自分の作業を振り返ってみると良さそう。\nよく考えると、自分も「プッシュしていいよ」「コミットして」みたいなことを毎回自然言語で送っている。固定の作業なら、コマンドにしてしまった方が楽だし確実だ。\n参考: スラッシュコマンド\n8. サブエージェントで複雑なワークフローを自動化 いくつかのサブエージェントを定期的に使っています：code-simplifier はClaudeの作業が終わった後にコードを簡潔にし、verify-app はClaude Codeをエンドツーエンドでテストするための詳細な手順を持っています。\n補足:\n設定場所: .claude/agents/ /agents コマンドで管理できる 組み込み: Plan subagent（計画用）、Explore subagent（高速検索）など 所感: サブエージェントも何に使えばよいか分からなかった。「Claudeが書いたコードを、別のClaudeが簡潔にする」という二段構えは面白い。AIの出力をAIがレビューするパターン。\n参考: サブエージェント\n9. PostToolUseフックでフォーマット自動化 PostToolUse フックを使ってClaudeのコードをフォーマットしています。Claudeは通常そのままでも整形されたコードを生成しますが、フックが残り10%を処理して、後でCIでフォーマットエラーが出るのを防いでいます。\n補足: PostToolUseフックは、ツール（Write, Edit等）の実行完了直後に自動実行されるスクリプト。\n.claude/settings.json での設定例:\n1 2 3 4 5 6 7 8 9 10 11 12 13 { \u0026#34;hooks\u0026#34;: { \u0026#34;PostToolUse\u0026#34;: [ { \u0026#34;matcher\u0026#34;: \u0026#34;Write|Edit\u0026#34;, \u0026#34;hooks\u0026#34;: [{ \u0026#34;type\u0026#34;: \u0026#34;command\u0026#34;, \u0026#34;command\u0026#34;: \u0026#34;./format.sh\u0026#34; }] } ] } } 所感: ファイル編集後に自動でフォーマッタを走らせる、という使い方は便利そう。CIで落ちる前に手元で直せる。\n参考: フック\n10. /permissionsで安全にパーミッション設定 --dangerously-skip-permissions は使っていません。代わりに /permissions を使って、自分の環境で安全だとわかっているbashコマンドを事前に許可し、不要なパーミッションプロンプトを避けています。\n補足: /permissions はパーミッションの表示・編集ができるコマンド。\n主なモード:\ndefault: 初回使用時に確認 acceptEdits: ファイル編集を自動承認 dontAsk: 事前承認済みのみ実行 所感: --dangerously-skip-permissions は以前ルートディレクトリ消した事故をしてた人がいた気がする。permissionsの登録も最近のアプデで楽になったし、それでよいかな。\n11. MCPで外部ツール連携 Claude Codeは私のすべてのツールを代わりに使ってくれます。よくSlackを検索して投稿したり（MCPサーバー経由）、BigQueryクエリを実行して分析の質問に答えたり、Sentryからエラーログを取得したりしています。\n所感: MCP連携は大事だが、どこまで連携するか問題がある。Slack、BigQuery、Sentryなど、開発に必要なツールを一元管理できるのは魅力的だが、最近は環境が変わったのもあって何も繋いでいない。\n12. 長時間タスクの管理 非常に長時間のタスクでは、(a) 完了時にバックグラウンドエージェントで作業を検証するようClaudeにプロンプトする、(b) エージェントのStopフックを使ってより確実に検証する、または(c) ralph-wiggumプラグインを使います。\n補足:\n--permission-mode dontAsk: 事前承認済みのツールのみ実行し、未承認なら停止 Stopフック: Claude停止時に自動で何か実行する ralph-wiggum: 公式ドキュメントに記載なし（カスタムプラグインの可能性） 所感: 長時間タスクを走らせている間、人間がボトルネックにならないようにする工夫。サンドボックス環境なら --permission-mode=dontAsk で放置できる。\n参考: フックガイド\n13. 検証手段を与える（最重要） 最後のヒント：Claude Codeから素晴らしい結果を得るために、おそらく最も重要なこと ── Claudeに自分の作業を検証する方法を与えてください。そのフィードバックループがあれば、最終結果の品質は2〜3倍になります。\nClaudeは、Claude Chrome拡張機能を使って、私がclaude.ai/codeにデプロイするすべての変更をテストしています。ブラウザを開き、UIをテストし、コードが動いてUXが良くなるまで繰り返します。\n補足: Chrome拡張機能を使うと、以下のことができる:\nDOM読み取り・クリック・入力 フォームテスト UIレイアウト検証 GIF記録 起動方法: claude --chrome\n所感: これが一番重要なポイント。検証手段があるかないかで、結果の品質が2〜3倍変わるというのは大きい。テストスイート、ブラウザ確認、シミュレータなど、何でもいいから「自己検証できる仕組み」を用意することが大事。\nなお、Chrome拡張はWSL環境では使えない（GitHub Issue #14367）。macOSかWindows（ネイティブ）環境が必要になる。WSLユーザーとしては少し残念だが、Mac側で開発するか、MCP経由でPlaywright等を使う方法もある。 → 最近のアプデで対応した。\n参考: Chrome統合\nまとめ Boris氏のTipsを振り返ると、以下の3つがポイントだと感じた：\n並列化: 複数のClaudeを同時に走らせて、人間がボトルネックにならないようにする 自動化: スラッシュコマンド、サブエージェント、フックで定型作業を自動化 検証: Claudeに自己検証する手段を与えることで、品質が2〜3倍になる 特に「検証手段を与える」は、すぐに実践できそうなポイント。まずはテストを書くことから始めてみたい。\nこの記事はClaude Codeと一緒に書きました。\n","permalink":"https://blog.intiramisu.com/posts/claude-code-tips-by-boris/","summary":"\u003cp\u003eClaude Codeの作者であるBoris氏が、自身のClaude Code活用法をX（旧Twitter）で共有していた。これが非常に参考になったので、翻訳と所感をまとめてみる。\u003c/p\u003e","tags":["Claude Code","AI","開発ツール","AIL-4"],"title":"【個人メモ】Claude Codeの作者Borisに学ぶ、13の活用Tips"},{"content":"概要 Observability Conference Tokyo 2025\n2025年10月27日開催。今回が初開催。 OpenTelemetryとGrafanaは好物かつ社内に浸透させたいので参加。\n資料は公開され次第、リンクを添付する。\nセッション 1. Affordable Observability: Strategy to Implementation LizさんによるKeynote。\n開発時に後回しになりがちなObservabilityを担保するための方法や、pitfallを回避するための方法、 テレメトリーデータのサンプリングを含む方法論について解説されていた。 私自身それなりの回数カンファレンスに赴いているものの、ここまでKeynoteとして完成されたものは多くない。 他の登壇者の方も影響を受けたためか、Keynoteから一部引用する形での登壇となったり、Keynoteで触れていた内容に触れる一幕があったりと大きな影響を与えていた。 これからObservabilityに取り組もうとする組織にとっても、これまで取り組んできたことのある組織にとっても非常に有用なKeynoteであり、定期的に振り返りたいと思えるKeynoteであった。\nなお、私はこんなことを記しながらも遅刻していたので早くもアーカイブを視聴したい気持ちである。\n2. 可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ LayerXの大平さんによるセッション。\n先のKeynoteの箇所で少し触れたが、大平さんはセッションの中で既にLizさんのKeynoteで触れた内容が出てきたことで多少なりとも影響を受けていた。 決してそれは聞き手としては悪い意味ではなく、多くの人が重要だと思っているからこそ内容の重複が発生していると感じた。\nセッションでは開発環境はステージング環境より前の、PRの承認が通った後にDeployする環境と定義付け、その環境に対してDatadogを導入していくというもの。 私の知っている限りではステージングでもない、開発環境に対してAPM製品を導入している事例は聞いたことがなく新鮮であった。また、Azure環境の経験が乏しい開発者が多かったことや、開発環境へ導入する経験が将来的に本番環境への導入時への足掛かりになる見立てであったことなど、導入に対しては非常に理解できるセッションであった。\n個人的には開発環境に対してもDatadogを導入することによるコスト負担と、導入によって得られた知見や開発者体験の向上といったメリットはどちらが優位であったかは気になった。 懇親会において大平さんとは会話したにも関わらず、聞きそびれてしまった。\n3. 映えないObservability MonotaROの岩永さんによるセッション。\nMonotaROにおいて一般的な文脈におけるObservability（映えるObservability）と、主にレガシー環境を始めとする制約のかかる環境におけるObservability（映えないObservability）に関するセッションであった。 日常的にTwitter(X)を見ていても、主に出てくるのはスタートアップを中心としたキラキラした世界における映えるObservabilityが中心だと感じる。その一方で、岩永さんが触れていたように実際にはレガシー環境のモダナイゼーションも多く存在しているし、現にここ1年くらい私もレガシーのことを考えてきた。 そのような環境では一般的なCloudNativeで取られる手法が取り込めないケースもある。\n本セッションは主にそういった制約下において、Observabilityによって解決されるべき課題が何であるかを模索することが大事であると理解した。ただし、これは映えるObservabilityでも同じことが言えると感じており、APM製品を導入して終わりな世界ではないはずである。 テレメトリーデータを取得することによって、どのような世界にしたいかを考えるべきなのだと思う。\n4. Observability文化はなぜ根付かないのか よくある失敗とその回避策 ULSコンサルティングの佐野さんによるランチセッション。\nObservabilityの担保のためにAPM製品が導入されることが多いが、それで終わりではないのはここまでのセッションの感想で触れた通りである。 本ランチセッションではより文化的な面から、Observabilityの担保が失敗する仕組みについて解説していた。\n懇親会やスポンサーブースで会話をしていて感じたが、Observabilityの導入を推進しようとしている人は開発や運用のチームに属しながらも他のチームを気にかけようとしている人が多いように感じる。というか、恐らくそのように立ち回らないとうまくいかないだろうとも思う。 これは本ランチセッションでも触れられていたように、Observabilityは開発チームが全く気にしなくて良いものでもないし、運用チームが全ての責任を負って遂行するものでもないからである。 お互いが歩み寄って関係性を構築した上で、必要なデータを擦り合わせたりダッシュボードを眺める機会が成功への近道である。 とはいっても、俗にいうJTCにおいて組織の壁を越えて文化を浸透させるのは容易なことではないのが現実だとも思ってしまった。 頑張りたい。\n5. プロファイルとAIエージェントによる効率的なデバッグ AWS Japanの山口さんのセッション。\n参加できなかったものの、Go Conference 2025のDay1でpprofに関するワークショップを開催していたことを思い出しながら聞いていた。私も時々トレースとプロファイリングの違いについて聞かれることがあり、プロファイリングは性能のために継続的に監視するものである一方、トレースはRequest単位で追いかけたい時に見るものと説明はしている。 本セッションでは非常にわかりやすく、他のテレメトリーデータとの違いを説明しており、今後の説明にはこれを利用させていただこうと思った。\nセッションではGoでの非効率なI/Oを発生させたコードでのFlameGraphを紹介し、ある程度知見のある人でないと読み解くのが難しいものであった。その一方で、生成AIを利用することである程度当たりをつけることが可能であることに言及。 プロファイルデータのみならずログを食べさせてあげても、それなりに良い回答が得られる体験は得ているため、改めて運用フェーズにおける生成AIとの相性の良さを感じた。\nちなみにこれはセッションと全く関係のない感想であるが、私が入社した少し後くらいからChatGPTは触れるような時代になっていたものの、業務におけるQA対応では先輩方から教えを乞いながら学んでいた。 ただ生成AIを利用するのが当たり前な昨今において、CSに関する知識やある程度低めのレイヤに関する知識はどうやって身につけるべきなのかは日常的に悩んでいる。\n6. ピーク時165万スパン/秒に立ち向かえ！オブザーバビリティコストを効率化するABEMAにおけるトレースサンプリングの実践的事例 Datadog Japanの逆井さんとAbemaTVの山本さんによるスポンサーセッション。\n実環境でのObservabilityにおいてSamplingを扱っていない人間なので非常に参考になった。 ヘッドで行うかテールで行うかの選択とそれぞれのメリデメや、実際にSamplingするにあたって落としてはいけないデータとある程度落として良いデータの判別をつけるための一種の判断材料になるセッションであった。 Datadogのスポンサーセッションであるものの、Datadogに限らずOpenTelemetryを利用しているのであれば参考になるセッションであると感じた。 セッション中で触れていた165万スパン/秒を全てDatadogで保存した場合に月12億円ものコストがかかるのは、単純に数字が大きく驚いた。\n7. オブザーバビリティと共に育てたID管理・認証認可基盤の歩み カミナシの高井さんによるセッション。\n認証認可の世界に限らず重要なコアロジックはライブラリ依存になっている一方で、十分なテレメトリーデータの確保をライブラリ経由で行えないことが課題となった事例が紹介されていた。 そのような状況の中で安易にライブラリのforkを行って管理地獄にするのではなく、プロファイルも併せて利用しつつ原因箇所の特定を行い、そもそもの認証方式自体を変更して対応した流れは素晴らしいものと感じた。 それと同時にライブラリを提供する側として仕事をすることがあるため、欲しいテレメトリーデータをユーザが取れるように拡張性を残すことの必要性を強く感じた。\nスポンサーブース 今回は全てのブースを巡った。特に記憶に残っているブースに関して記載する。\n1. Grafana Labs Grafana大好きおじさんなので、ブースでTシャツを頂けて大喜び。 あまり技術的な話をしないまま次のブースに行ってしまったのが心残り。\n2. カオナビ OpenTelemetryとかAPMツールはあくまでもツールであって、それ自体の導入で全てが上手くいく訳では無い旨の話を長々とさせていただいた。 銀の弾丸は存在しないし、組織によってやることは異なるから文化の醸造が大事だと改めて感じた。\n3. PagerDuty PagerDutyで出来ることを熱く語っていただいた。PagerDutyでも実際に十分活用できているところは少ないことも学んだ。 APM製品のみならずインシデント管理の領域でもそうなってしまう悲しみも感じた。\n全体的な感想 初開催となったObservability Conference Tokyo 2025であったが、非の打ち所がないカンファレンスであった。 運営の方の対応が非常に丁寧であったことは勿論のこと、会場のwifiは問題なく繋がり、コーヒーや軽食の提供まであり1日を通じて楽しめた。 次回の開催が未定であるものの、個人的にObservabilityの領域が一番好きなこともあり来年の開催を楽しみにしている。\n","permalink":"https://blog.intiramisu.com/posts/observability-conference-tokyo-2025/","summary":"\u003ch2 id=\"概要\"\u003e概要\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://o11ycon.jp/\"\u003eObservability Conference Tokyo 2025\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e2025年10月27日開催。今回が初開催。\nOpenTelemetryとGrafanaは好物かつ社内に浸透させたいので参加。\u003c/p\u003e\n\u003cp\u003e資料は公開され次第、リンクを添付する。\u003c/p\u003e","tags":["参加レポート","AIL-1"],"title":"【参加レポート】Observability Conference Tokyo 2025"},{"content":"概要 Go Conference 2025\n2025年9月27日と28日の2日間開催。 昨年行きたいと思った時には既にチケットは完売、今年が初参加。\n両日参加したかったものの、27日は都合が合わず28日のみの感想となる。 また夕方も都合があり17時頃までの参加となった。\n聴講したセッションおよびスポンサーブースでの感想を記載する。\nなお、Go言語の経験は約3年程度。 業務ではバックエンドでゴリゴリAPIを書くよりかはミドル寄りの人間であり、 OSSとして公開されているAILERON Gatewayでの開発が主。 興味があれば覗いてみて欲しい。\nセッション 1. Go1.25新機能 testing/synctest で高速 \u0026amp; 確実な並列テストを実現する方法 Panaさんによる2日目最初のセッション。\n個人的にGo 1.25のリリースノートを眺めていた時に気になっていたsynctestに焦点を当てたセッション。同期的なテストと非同期的なテストの違いからの問題提起が非常に分かりやすく自然とセッションの理解が進んだ。\nただ、セッション中に頻出した単語である\u0026quot;durably blocked\u0026quot;がよく分かっていなかったため、このタイミングで調べる。すると、1日目に発表されたDaiki Kuboさんの「deep dive into testing/synctest」がヒットした。\n引用させていただくと、\nbubble外のイベントでは解除されないブロック状態 例えば、\ntime.Sleep bubble内のchannelに対してのsend/receive selectのケースがbubble内のchannel sync.Cond.wait など・・・ Durably Blockedではないもの:\nbubble外のイベントやゴルーチンによって解除されうるもの これによって何が起きるか:\n仮想時間が進まず bubbleがidleとみなされずWaitは永遠にブロックされる 分かったような分からないような……。 GoDocを見に行く。\nが、定義なので同じことが書いてある。それはそう。 time.Sleepを筆頭に詰みの状態(durably blocked)になったらbubbleの時刻が進むという話なのだろうな。 その上でsynctest.Waitはgoroutineの終了ではなくdurably blockedになることを待っている作り。\nPanaさんのセッションに戻ると、この内容を40分のセッションに詰め込んで解説されているのが凄すぎる。 自分で使うとなるとgoroutineを正確に把握したうえで実装する必要があるので、実装時もレビュー時も中々大変そうに思えてしまった。 その分、並行テストを高速かつ安定して実施するポテンシャルを秘めているので使いこなせると良いなと感じた。\n2. Goに育てられ開発者向けセキュリティ事業を立ち上げた僕が今向き合う、AI × セキュリティの最前線 Koki Ideさんによるスポンサーセッション。 GMO Flatt SecurityのCEOによる発表であり、セキュリティ診断AIエージェント Takumiを中心とした紹介。\nあまり個人でClaude CodeはじめAIエージェントに脆弱性を見つけさせるような使い方はしないものの、 Claude Codeの誤検知率と比較した際のTakumiの誤検知率の低さは目を惹いた。機会があれば利用したい。\n3. Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する Takeru Hayasakaさんによるセッション。\n普段ネットワーク屋さんをしていないこともあり、恥ずかしながらMultipath TCP自体初めて知った。 アプリ側は従来通りのTCPの使い勝手のまま、複数のTCPコネクションをsubflowと呼ばれる単位で束ねる仕組みのこと。 仕組みとしては十分に理解可能かつ、従来のTCPコネクションを拡張した仕組みであることから、 SYN, SYN+ACK, ACKのフロー上に拡張してやり取りしているのは納得がいくとともに面白い。\nGoで利用する際にも基本的にはデフォルトで良いのも意識することが少なくて良い作りだと感じた。 普段あまり意識しないレイヤーの話で楽しかった。\n4. Go1.24時代のユニットテスト品質向上 Shotaro Watanabeさんによるセッション。\n1.24で導入されたtesting.T.Context()を利用するとdefer忘れが無くなることでgoroutine leakが防げるようになったことと、 uber-go/mockを利用することでDBを含めたテストでもモックによって、信頼可能なテストが書けるようになったという話であった。 過去、go-redisを利用してredisのunit testを書いたことを思い出しながら聞いていた。\nまた本セッションではAtS (Ask the Speaker)で会話させていただいた。 リリースを最優先していることでテストを書くことが後回しになった結果、 誰かが書いたコードの単体テストを書かざるを得ない状況になっていたとのこと。\nこの辺りの文化の醸造は組織や人によっても状況が異なるので難しいと思いつつも、 やっぱりテスト無いと難しくない……？という話になった。\n2日目しか参加していないものの、このくらいのレベル感のセッションがもう少しあっても良かったように感じた。\n5. Goのビルドシステムの変遷 ymotongpooさんによるGo昔話なセッション。\nGoに触れた時にはgo modだったので過去の話を知ることが出来た貴重な機会であった。 Go 1からも色々と紆余曲折あったり、Go開発チームの強気の姿勢だったりと面白い箇所が幾つもあった。\n20分のShort Sessionに収めるにはあまりにも濃いセッションであったので、 省かれてしまった歴史に関してはまたどこかで知りたい。\n楽しみ。\n100いいね言ったので少しずつ書きます https://t.co/N4g9kcdCUD\n\u0026mdash; Yoshi Yamaguchi (@ymotongpoo) September 28, 2025 6. 0→1製品の毎週リリースを支えるGoパッケージ戦略——AI時代のPackage by Feature実践 OPTiM 上原さんによるスポンサーセッション。\nPackage by LayerとPackage by Featureの両方を比較し、それぞれのメリデメ比較をされていた。 どちらのPackage構成も良い部分があり、規模や目的に応じて最適解を模索するのが良さそう。 Contextの関係上、Package by Featureの方がAIとの親和性が高い点は今時の切り口で良かった。\n7. Swiss Table の実装に Deep Dive ! Keisuke Ishigamiさんによるセッション。\n拝聴している時には、難しい……という感じであったが、 Go Conference 2024でのrepluさんの資料「Understanding SwissTable for map performance」を見ながらだと、かなり腑に落ちた。\niterationのランダム化の仕組みに関しては普段あまり意識しない部分でもあり知ることが出来て良かった。 ただこれでも全体の半分くらいしか理解できていない気がしている……難しい……。\n8. なぜGoのジェネリクスはこの形なのか？ - Featherweight Goが明かす設計の核心 Ryotaro Suzukiさんによるセッション。\nそもそも当初、\u0026ldquo;contracts\u0026quot;と呼ばれる概念を導入しようとしていたこと自体知らなかった。 またJavaのジェネリクスの考え方をベースにGoにも持ち込んでいたのも面白い。\nが、理解できたのもこの辺りまで。FG/FGG辺りの話からついていけず。理解できる日は来るのだろうか。\n9. Green Tea Garbage Collector の今：Go言語のコアチームによる試行錯誤の過程と共にメモリ管理最適化の実装を読み解く zcheeさんによるセッション。\n1.25でexperimentalに利用可能となったGreen Tea GCに関する解説。 リリースノート等で今までの単位より細かく見るようにした結果、効率が良くなった、らしい。程度の知識で拝聴。\nまさかCPUとDRAMの性能乖離による影響がGCに響いているとは思わなかった。 意外だったのは既存のTri-color Parallel Markingから飛躍したアルゴリズムではなくて、 改善を加えつつ特定のケースにおける最適化を実施したようなもので、論理的にやってるんだなと感じた。それはそう。 各所で性能向上した話を聞くので、そろそろ利用してみるかという気持ちになった。\nスポンサーブース 1. ファインディ株式会社 Go-typingを開催していた。Macのキーボードは慣れないが賢者らしい。 Goを書く速度は異常に遅いので恥ずかしい。\nGo conference2025で #Findy Go-typingをプレイしました！スコアは133100点 称号は「賢者Gopher」を獲得しました！（速度：5.8key/秒、ミス：11key） #gocon\n\u0026mdash; いんてぃ (@intiramisu_) September 28, 2025 2. 株式会社カンム Go Conference開催前日の金曜日にCTFを開催していることを知った。\nGo Conference 2025の開催日が近づいてきました\nカンム恒例のCapture The Flagに以下のURLから挑戦できますhttps://t.co/buF5UlkDl3\nユーザー名：kanmu\nパスワード：gocon2025\nCTF正解者には、ブースでノベルティをプレゼント予定です。皆さんの解答を楽しみにしております！#gocon #kanmu2025ctf\n\u0026mdash; nchika (@ARC_AED) September 26, 2025 解いたので堅牢なソースを頂いた。\n堅牢なソースゲット pic.twitter.com/LlzFlVwgQg\n\u0026mdash; いんてぃ (@intiramisu_) September 28, 2025 ラベルにもGoのコードが記載されており、カンムのサイトへ飛べるURLが出てきて最後まで楽しかった。\n3. 株式会社クロステック・マネジメント 大きく京都芸術大学と書かれていて目を惹かれたブース。 多摩美術大学や東京藝術大学と比較してマイナーであることと、校風として反骨精神が強いことから、 将来的には多くの人が学べるプラットフォームの場を提供すると熱く語っていたのが印象的。\n4. 株式会社はてな 国産APMツールであるMackerelの紹介を行っていた。 Grafana好きおじさんなので、Mackerelはこうなって欲しいという話をした。 国産という強み、開発者と物理的に距離が近いことが他のAPMツールとは大きく異なるので今後が楽しみ。\n全体的な感想 初？の2日間開催となり運営の方々には本当に頭が上がらない。 初参加であったものの全体的に楽しめ、来年も参加したい気になった。 ただ自身のGoの力不足なのもあるが、全体的に難度の高いセッションが多く良くも悪くもレベルが高く感じた。 次回はもう少し初心者、中級者向けのセッションがあると良いかと思った。 心残りとしてはワークショップに参加したかったので、来年も2日間開催であれば分散していただけると嬉しい。\n","permalink":"https://blog.intiramisu.com/posts/go-conference-2025/","summary":"\u003ch2 id=\"概要\"\u003e概要\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://gocon.jp/2025/\"\u003eGo Conference 2025\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e2025年9月27日と28日の2日間開催。\n昨年行きたいと思った時には既にチケットは完売、今年が初参加。\u003c/p\u003e\n\u003cp\u003e両日参加したかったものの、27日は都合が合わず28日のみの感想となる。\nまた夕方も都合があり17時頃までの参加となった。\u003c/p\u003e","tags":["参加レポート","Go","AIL-1"],"title":"【参加レポート】Go Conference 2025"},{"content":" プロジェクト・ヘイル・メアリー 上 プロジェクト・ヘイル・メアリー 下 評価 ★★★☆☆ 面白くはあったけど……な作品\n前置き 普段、読書感想を始めとして文章はあまり書かない人間である。 また主に読むジャンルはファンタジー一辺倒であり、SFに関しては無知であることに留意して頂きたい。 SFの経験としては小学生の頃に読んだ星新一程度であり、数年前に三体が話題となっていた記憶があるがこちらは未読。\n感想 決して面白く無い訳では無いのだが、SNSで見られるように大絶賛されている理由が分からなかった。 ネタバレを避けて本作品が評価されているポイント、話題となっているポイントを挙げれば下記となる。\nネタバレ厳禁な展開であること 翻訳が苦手な人にとっても読みやすい作品であること 2026年に映画化が決定したこと それぞれについて見ていく。\nネタバレ厳禁な展開 他の方の本作品の感想や推薦文では、 「ネタバレ厳禁」「映画の予告編を見るな」「本の帯さえ見るな」 といった表現を多く見かけた。 しかしいざ読み終わると、確かにネタバレされると面白くは無いと想像できるが、 それはおおよそ全ての作品で言えるのではないか？という感想を抱いた。\n上巻の中盤まで読み進めれば本作品は頭から時系列順に並んでいないことは分かり、 終盤にかけて大きな転換点を迎えるわけであり、それらは間違いなく本作品の根幹を成す部分である。 しかしどの作品にも 起承転結 における 「承」「転」 の部分は含まれ、プロジェクト・ヘイル・メアリーに限ったことではない。 最後まで読み切った感想として、そこまで何かを避ける必要があったのかと言われると分からない。\n翻訳の読みやすさ 個人的に本作品の評価を大きく分けるのは翻訳、翻訳家との相性だと考える。 私は本作品を読み進める中で「プロジェクト・ヘイル・メアリー　誤訳」と検索してしまう大きなミスを犯した。 基本的に私は1つの作品を読み終わるまで他者の感想は見ないようにしているが、上巻の途中で翻訳のクセが合わず同様に感じる人を探してしまった。\nそこで出会ったのが下記noteである。 本作品の内容に大きく関わるため、ネタバレを許容できる方のみアクセスして頂きたい。\nプロジェクト・ヘイル・メアリーの翻訳について\n誤訳とも捉えかねられない翻訳との相性が悪く、最後まで読み切るまで翻訳のことは常に頭に残ってしまった。\nまた本作品において、主人公の口調は特徴のあるものとなっている。 これは主人公が置かれている環境の都合上、独り言として言葉にしなければ何が起こっていて、何をしているのか読者が直接的に理解できないためと解釈している。 この主人公の独り言に強いクセがあり、人によっては読みやすいと感じるのかもしれないが、私には合わなかった。\n映画化の予定 SF同様に映像作品は日常的に触れてないため映画のPVを含め見ておらず、全くもって完全な推測であるが、 本作品は書籍で体験するより映画で体験した方が面白い類のものであると感じた。 主人公の語り口調は映画化に伴って変わるかもしれないし、変わらないかもしれない。 それでも主人公の置かれた環境での一連の操作を逐一、活字で読んでいくよりかは遥かに楽しい体験となるのではなかろうか。\nまとめ ただ単にnot for meであったというだけであり、展開は良く面白い作品ではあったが、人に薦めるかと言われると悩む作品。\n","permalink":"https://blog.intiramisu.com/posts/project-hail-mary-review/","summary":"\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.hayakawa-online.co.jp/shop/g/g0005210070/\"\u003eプロジェクト・ヘイル・メアリー 上\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.hayakawa-online.co.jp/shop/g/g0005210071/\"\u003eプロジェクト・ヘイル・メアリー 下\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"評価\"\u003e評価\u003c/h2\u003e\n\u003cp\u003e★★★☆☆\n面白くはあったけど……な作品\u003c/p\u003e\n\u003ch2 id=\"前置き\"\u003e前置き\u003c/h2\u003e\n\u003cp\u003e普段、読書感想を始めとして文章はあまり書かない人間である。\nまた主に読むジャンルはファンタジー一辺倒であり、SFに関しては無知であることに留意して頂きたい。\nSFの経験としては小学生の頃に読んだ星新一程度であり、数年前に三体が話題となっていた記憶があるがこちらは未読。\u003c/p\u003e","tags":["読書感想","AIL-1"],"title":"【読書感想】プロジェクト・ヘイル・メアリー"}]