【謎現象】MXR Carbon CopyとJ.Rockett Archerを組み合わせるとディレイ音がほぼ鳴らない

今回はギターネタです。
最近MXR Carbon Copyというアナログディレイを買いました。

アナログディレイ、やっぱり気持ちいいですね〜！・・・と言いたいのですが、なんか音が変。
なんでだ？もしかして壊れてる？？
と思っていろいろ調べたところ、ある事実に気付きました。

それは、「J.Rockett Archerが手前につないであると、Carbon Copyのディレイ音がほぼ鳴らない」という謎現象です😱

動画で確認してみる

テキストで説明するより音を聞いてもらった方が早いので動画を撮ってきました。

www.youtube.com

動画の内容はこんな感じです。

Carbon Copy単体 ✅

問題なくきれいにディレイ音が鳴っています。

Archer + Carbon Copy ❌

Archerをオフ（バイパス）、Carbon Copyをオンにすると、ディレイ音が1回しか鳴りません！

Archerもオンにすると、ディレイ音のリピート回数は少し伸びますが、Carbon Copy単体のときに比べると音質が悪く、ディレイ音の余韻も少し不自然です。

EP Booster + Carbon Copy（比較用） ✅

比較用にEP Boosterをつないだ場合も検証してみました。
これはCarbon Copyだけオンにしたときも、EP BoosterとCarbon Copyを両方オンにしたときも問題ありません。

Archer + EP Booster + Carbon Copy（比較用）❌? ✅?

ArcherとEP BoosterとCarbon Copyをシリアル接続した場合も検証してみました。

Carbon Copyだけオンにしたときは、「Archer + Carbon Copy」のときと同様に全然ダメです。
ディレイ音が1回しか鳴りません。

EPとCarbon Copyをオン、Archerをオフにすると、3〜4回リピートするようになりますが、やはりまだ不自然です。

3台ともオンにすると、そこそこリピート回数が増えます。
これぐらいならCarbon Copy単体の場合と比較してもOKな感じがします。

結果をまとめるとこんな感じ

動画の検証結果を表にまとめるとこんな感じになります。

Archer	-	OFF	ON	-	-	OFF	OFF	ON
EP Booster	-	-	-	OFF	ON	OFF	ON	ON
Carbon Copy	ON	ON	ON	ON	ON	ON	ON	ON
音質	✅	❌	△	✅	✅	❌	△	✅

バイパス（スイッチオフ）状態のArcherがCarbon Copyの手前にあると、Carbon Copyの機嫌が特に悪くなるようです。

原因は何？直し方はあるの？？

原因はよくわかりません！直し方もわかりません！
誰かわかる人がいたら教えてください！！

素人の推測ですが、Archerは若干特殊なエフェクターで、

• バッファードバイパスである（オフの状態でもギターの信号は内部の電気回路を通っている）
• ペダル内部で9Vから18Vに昇圧している

という特徴があります。

このへんの仕様がもしかするとCarbon Copyの機嫌を損ねる原因になっているのかもしれません。

ちなみにChat GPTに言わせると、

ArcherのバッファとCarbon Copyの入力インピーダンスの相性問題ですね。
特にアナログディレイってデジタルと違ってすごく原始的なフィードバック方式だから、前段の信号特性にめちゃくちゃ影響受けるんだよね。

だそうです。知らんけど。

ただ、単純にインピーダンスの問題だけならEP Boosterをオンにしたときもインピーダンスは下がる（＝状況としてはArcherと大差なくなる）はずなので、同じような問題は起きるんじゃないかなーと思ってます。

Archerのアウトプットだけ、Carbon Copyの秘孔を突くような、何か良からぬ信号が出力されているんでしょうか。。

参考：海外の掲示板でも似た報告が！？

同じような現象がネット上に報告されていないか確認したところ、1件だけよく似た話が見つかりました。

（ChatGPTによる翻訳。強調は筆者）

私はこの件についてJ. Rockettにメールしましたが、解決策の返答はありません。

最近Archerを手に入れて、音は良いのですが、私のMesa/Boogie Mark V:25のエフェクトループ内で使っているMalekko Ekko 616アナログディレイに思わぬ副作用を引き起こしています。

Archerをアンプのインプットに接続し、Archerがオンでもオフでも、アナログディレイのリピートが1回しか鳴らなくなってしまいます。

Archerを完全に接続から外すと、ディレイは通常通りのリピート数を出すようになります。
ディレイのミックスやリピートレベルを上げても変化はありません。

同様に、MXR Carbon Copyを使ってみても同じ現象が起こりました。
Archerがオンでもバイパスでもです。

なお、このアンプのエフェクトループにはセンド・リターンレベルの調整機能はありません。

一方で、ArcherをJHS Lucky Cat（デジタルディレイ）と一緒に使うと、リピートは正常に動作します。

Archerは他のペダルと組み合わせた場合には特に問題は起きません。

この現象を経験した方や、アナログディレイとの相性を改善する方法をご存じの方はいませんか？

お読みいただきありがとうございます。

https://www.reddit.com/r/guitarpedals/comments/aglh0d/question_j_rockett_archer_messing_with_analog/?rdt=38424

うむ、内容を読む限り、僕と同じ現象が起きていますね。

この人の場合、

• Carbon CopyだけでなくMalekko Ekko 616というアナログディレイでも同じ問題が起きている
• JHS Lucky Catというデジタルディレイでは問題は起きなかった

と書いています。

残念なことに有力なリプライは付かず、質問者の人いわく、「アナログディレイが使えないのは致命的なのでArcherは売った」と書いています😭
「メーカーのJ.Rockettに問い合わせても回答がもらえなかった」という点も痛いですね。。

まとめ

というわけで、今回のエントリでは、MXR Carbon CopyとJ.Rockett Archerを組み合わせるとディレイ音がほぼ鳴らない、という謎現象について紹介してみました。

いや〜、困りましたねえ。
ArcherもCarbon Copyも気に入っているのでどちらも手放したくないんですが、場合によってはどっちかを買い換える必要があるのかな〜と思っています😣

買い換えるならディレイの方かな〜。
何かおすすめのディレイをご存じの方がいたら教えてください！

MXR M169 CC ANALOG DELAY

【国内正規品】 J. Rockett Audio Designs (JRAD) ギターエフェクター Archer OD アーチャー オーバードライブ

Xotic エキゾチック エフェクター ブースター EP Booster 【国内正規品】 黒,銀

ちなみに最近気になってるディレイはこれです↓
1回試奏してみたい〜！

Limetone Audio buddy コンパクトエフェクター ディレイ ライムトーンオーディオ

【書評】もっといいコメントの書き方がわかる！『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』

はじめに

翔泳社さんより、『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』をご恵贈いただきました。

実はこの本は発売前から気になっていて、Amazonですでに予約購入していました。
ところが今回、翔泳社さんから本書を贈ってもらえることができたので、僕としては願ったり叶ったりでした😄
翔泳社さん、どうもありがとうございます！

伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書

どんな本なのか？

ひとことで言うと、プルリク上でITエンジニア同士が交わすテキストコミュニケーションに関する本です。

「こういうコメントはGOOD」「こういうコメントはBAD（なのでこう改善しましょう）」といったコードレビュー上のポイントが、豊富な具体例とともに説明されています。

どんな人におすすめか？

これはズバリ、実務に入ったばかりの新人エンジニアさんですね！
コードレビューをする側（レビュアー）よりも、される側（レビュイー）に回ることが多いITエンジニアのみなさんにおすすめです。

「コードレビューって何？」「レビューコメントが付いたけど、どう対処すればいいの？？」と右往左往している新人エンジニアさんは、本書を読むことでコードレビューに対する向き合い方や心の準備ができるようになると思います。

一方、本書はレビュイーだけでなく、レビュアーにもお勧めです。
なぜなら「こういうコメントは書いちゃダメ」という、レビュアー向けのNG例とその改善策もたくさん載っているからです。

最近レビューする側にも回るようになった人は、本書を読むことで「そういえばあのコメントはわかりにくかったかも」とか「ああいう書き方をすると、相手を萎縮させちゃったかもしれないなあ」といった反省点が見つかったりするんじゃないかなーと思います。

僕の感想：あるあるパターンの連続！開発チーム全員で読んでおくと良さそう

僕が本書に別名を付けるなら「コードレビューあるある大全」と名付けたいです。

というのも、本書を読む進めていくと、「あるある！」「あー、これもよくある！」と、次から次に過去に自分も遭遇したことのあるコードレビューコメントの例が登場したからです。
「よくこんなにあるある事例を集めてきたな〜」と感心するほどです。

こういったNGパターンは、おそらくどの現場でもよく見かける光景なんでしょうね。
ですので、きっとこのブログを読んでいるあなたの現場でも絶対に役立つ情報が載っているはずです。

コードレビューを必須にしている現場で働いているみなさんは、開発メンバー全員で本書を読むといいと思います。
とくに、輪読会形式で読んでいくと「これはうちでもよくあるよね」とか「今度からみんなでこの点に気を付けよう！」といった具合に、参加者同士で話が盛り上がりそうな予感がします 😄

その他、思ったことなど

かわいいイラストが多くて読みやすい

「本を読むのが苦手」「文字ばっかり読むのはしんどい」と考えている人も大丈夫！
かわいいイラストがたくさん載っていて、普段本をあまり読まない人もすっと理解できるような構成になっています。

コード例はRubyが多め（でも誰でも読める）

執筆者がRuby界隈の方たちなので、コード例はRubyやRailsを想定したものが多かったです。
とはいえ、コードが主役の本ではないので、Rubyプログラマ以外の人が読んでもまったく問題ありません。

テクニカルな話は少なめ

本書を読む前は「コードレビュー全般に関する本」だと思っていましたが、実際に読んでみると「コードレビューにおけるテキストコミュニケーションに特化した本」だとわかりました。
なので「コードレビューするときは、こういう観点でコードをチェックしよう」というようなテクニカルな話は本書には出てきません。
個人的にはそういう話も読みたかった、というか、僕が書きたいな！！

一方、ソニックガーデンのコードレビューでは……

ちなみに弊社ソニックガーデンではこんなに丁寧ではなく、もっと殺伐としたやりとりが交わされています（苦笑）。

というと、「めっちゃ怖い」と思われるかもしれませんが、これはレビュアーもレビュイーもどちらも優れたプログラマで、なおかつお互いを技術者としてリスペクトしあえているからです。
加えて、普段からよくZoom等で話していて、お互いの人となりがよくわかっているから、という側面もあります。

つまり、互いに気を遣わなくてもよい関係性を構築できているので、コードレビューのコメント自体はシンプルで素っ気ないものになることが多いです。

たとえば、こんな感じですね。

素っ気ないコメントでもお互いに気分を害さないのであれば、コードレビューにかける時間も短くて済むので効率的です。

まとめ

というわけで、今回は『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』の感想を書いてみました。

コードレビューコメントに特化した本というのは、おそらく今までなかったと思います。
今までなかったけど、コードレビューの文化は日本のIT業界にかなり浸透してきているはずです。
ですので、「コードレビューやってます」という現場で働いているITエンジニアは全員必読の一冊、と言っても過言ではないかもしれません。

若手ITエンジニアのみなさんはもちろん、ベテランエンジニアのみなさんもプルリク上のテキストコミュニケーションを見直すために、本書を一度手に取ってみることをお勧めします！

伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書

あわせて読みたい

これに関連して、良いコミットや良いプルリクエストに関する議論を僕も以前、レバテックラボさんのサイトに寄稿しました。
「伝わるコードレビュー」とあわせて、こちらもぜひチェックしてみてください。

levtech.jp

levtech.jp

なお、個人的なコードレビューの極意は「自分のことを棚に上げる」ですｗ

qiita.com

「なぜあなたの記事には「いいね」が付かないのか？」を解説してみた＆Qiitaのスライド機能の感想など #QiitaConference

前回のエントリでもお知らせしたとおり、2025年4月23日に開催されたQiita Conference 2025で、「なぜあなたの記事には「いいね」が付かないのか？〜あるいは「いいね」よりも大事な技術記事の価値について〜」という発表をしました。

当日使った資料はこちらです。

qiita.com

いつもはKeyNoteを使ってスライドを作るのですが、今回は訳あってQiitaのスライド機能を使ってみました（理由は後述）。

タイトルのとおり、この発表ではQiitaに記事を書いてもなかなか「いいね」が付かない人たちに向けて、いいねが付かない理由と、どうすればいいねが付きやすくなるのかを解説してみました・・・と言いたいところですが、それは表向きの（？）テーマで、本当は「いいねのために記事を書いても仕方ないんやで」というメッセージが、この発表の真のテーマです。

なお、スライドは全画面表示にして、なるべく大きなモニタで見るのをお勧めします。
具体的にはこれぐらいのサイズ感です↓

Qiitaのスライド機能を使った理由

前述のとおり、今回初めてQiitaのスライド機能を使って登壇用の資料を作ってみました。
スライドモードについて | Qiita ヘルプ

なんで、KeynoteじゃなくてQiitaのスライド機能にしたのかというと、3〜4月は息子の大学入学準備にかかりっきりで資料作成のスタートが遅くなってしまったため、スライド作成に費やす時間を減らしたかったからです。
もう少し詳しく言うと、「自由度が高すぎるKeynoteだと、いつもの癖でスライドいじりに時間をかけすぎてしまうので、あえて自由度の低いQiitaのスライド機能を使って、自分自身に制約を課そうと考えたから」です。

決して、「発表のついでにみんなに「いいね」を付けてもらおうとしたから」ではありません！😅
（まあ、それはスライドを作ってる途中に「あ、そういえば💡」とひらめいたのですがw）

実際、マークダウンでちゃちゃちゃっとテキストを書いていったら8割方できてしまったので、初速は結構速かったですね。
ただし、「やっぱりここをこうしたい」といういつものこだわり癖が出てくると、逆にKeynoteのような自由度がないぶん、「うーん、どうしよう？」と頭を抱えることが多かったです。

具体的には以下のような内容です。

スライドの縦横比やサイズが固定されない

Keynoteだとスライドを新規作成するタイミングで縦横比やサイズが固定されますが、Qiitaのスライド機能はブラウザのウインドウサイズに応じて縦横比やサイズが変わります。
ですので、「このテキストや画像が画面内に収まるかどうか？」は、そのときどきのブラウザのウインドウサイズによって答えが変わってきます。

今回は「モニタの解像度＝1280x828」「Chromeの拡大率＝90%」という設定を当日の発表で使うことにして、その設定でプレビューしながらテキストや画像を収めるように調整しました。
でもKeynoteみたいに「スライドの枠はこれだけです！」と、最初から固定されている方がプレビューの手間がかからず楽ですね。

文字のサイズをむりやりCSSでいじった

デフォルトだと、以下のようにQiitaのスライド機能はリストの2段目以降も文字サイズが変わりません。

ただ、これだとメリハリが付かず、読みにくい気がしたので、「2段目のテキストサイズだけちょっと小さくする」という対応を入れました。
よ〜く見ると、「釣りタイトル」のような文字が少し小さくなっているのがわかるはずです。

これはどうやったのかというと、StylusというChrome extensionをインストールし、以下のようなCSSをqiita.comに適用しました。

.slideMode-Viewer_content ul ul {
    font-size: 0.85em;
}

ですので、この設定を入れておかないと、僕の環境とみなさんの環境では、若干スライドの見え方が異なる、という違いが発生します。

画像の上に文字を重ねられない

Qiitaのスライド機能はマークダウンベースなので、当たり前と言えば、当たり前なのですが、画像の上に説明用の文字を入れたりすることもできません。
ですので、予め画像の中に文字を埋め込んでおいて、それを貼り付けました。

たとえば以下の例では「ランキング1位」とか「投稿数388件」のような文字を事前に埋め込んだ画像をQiitaにアップしています。

ただ、これって「文字を埋め込んだ画像」を作成するためにKeynoteを使ったりしているので、本末転倒というか、それなら最初からKeynote使っとけよ、という気がしましたね😅

もともとは「そこまでスライドに時間をかけない」という意気込みでQiitaのスライド機能を使い始めたのですが、リハーサルを繰り返していると、「うーん、やっぱりここはこうしたい」という欲が出てきてしまって、余計に時間がかかることになってしまいましたw

その他、むりやりハックした箇所多数💧

以下のスライドを見てください。

何の変哲もない、文字とQRコードが貼り付けられたページに見えると思いますが、これってどういうマークダウンテキストを書いたかわかりますか？

答えは、こうです↓

## この記事（スライド）も「いいね」してね！😘<br><br>感想や質問もお気軽にどうぞ<br><br>![qr.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/7465/ce15e11e-3bc9-43f2-9a11-1d42fbbc9958.png)

なんと、1つの見出しの中にbrタグと画像を全部詰め込んでいます!!

「こういうレイアウトで表示したいな〜」「でも、これどうやればいいんだ？」と、試行錯誤した結果、行き着いたのがこのやり方でした。
Keynoteならちょちょいのちょい！で、終わってたでしょうね〜。

というわけで、僕のように「どうあがいてもスライドの見せ方にはついこだわってしまう」というタイプの人間は、最初からKeynoteを使った方が良かったかもしれません😅

ですが、「そこまでスライドの見せ方にはこだわらない」「時間がないから時間最優先でスライドを作りたい」という人には、Qiitaのスライド機能は便利だと思います！

Qiitaのスライド機能のいいところ

なんかQiitaのスライド機能の悪口(?)ばかりを書いてしまったので、よかったところも紹介しておきます！

スライドに「いいね」を付けてもらえる

Qiitaのスライド機能は、通常のQiita記事の一種なので、普通に「いいね」や「ストック」ができます。
今回はQiita主催のイベントだったこともあり、視聴者にもQiitaユーザーが多かったと思われるため、記事にたくさん「いいね」を付けてもらえました。

一晩で通知欄も「99+」になってしまいましたw

発表を聞いてくれた人の反応がこうやってすぐに伝わってくるのは、登壇者としてとても嬉しかったです😄

スマホ表示でも意外と見やすい

もともとPC画面の表示しか考えずに作成したのですが、スマホで表示しても意外と見やすかったです。

これはブラウザのウインドウサイズに応じて縦横比やサイズが変わる点が、メリットとして働いた例ですね。

他の人に事前レビューしてもらいやすい

作成した資料を「限定公開」にしておけば、全体公開する前でもURLを渡すだけで関係者にレビューしてもらうことができます。

今回はQiitaの運営スタッフに「画面共有がうまくいかなかったときの保険」としてスライドを共有する必要があったので、この機能が役に立ちました。

しかも、こちらでスライドを変更して保存すれば、それがそのまま相手側の画面に即反映される点も便利ですね。
Keynoteとかだと、「何か修正を加えるたびに、KeynoteをPDFエクスポート → 何らかの方法で運営スタッフに向けてアップロード」みたいな手順を取らないといけなかったと思います。

まとめ

というわけで、今回のエントリではQiita Conference 2025で登壇してきましたよ、という話と、Qiitaのスライド機能についていろいろ語ってみました。

僕の発表を聞いてくださったみなさん、どうもありがとうございました！
当日聞けなかったという人も、おそらく後日動画が公開されると思うので、そちらをチェックしてみてください。

また、発表聞いたよ、スライド見たよ、という人で、まだ「いいね」を押してない方は、ぜひポチッといいねをよろしくお願いします！！
↓
qiita.com

おまけ：実はこのスライド自体が「いいね」してもらいやすい工夫をしている

発表の中で「こんな記事はいいねしてもらいやすい」という話をしましたが、実はこのスライド自体がそのフォーマットに沿っていることに気づいた人はおられるでしょうか？

よかったらスライドを見ながら、「たしかにこのスライド自体もそうなってるやん！」と思ってもらえると嬉しいです 😆