<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>NiceDayUp</title>
<link>https://ameblo.jp/nicedayup/</link>
<atom:link href="https://rssblog.ameba.jp/nicedayup/rss20.xml" rel="self" type="application/rss+xml" />
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
<description>Practical notes on AI website design and build briefs.</description>
<language>ja</language>
<item>
<title>ゲームのアイデアを一文で書き、ブラウザで試せる形へ</title>
<description>
<![CDATA[ <p>ゲームを作ってみたいと思っても、最初にエンジンのインストールやファイル構成を学ぶ必要があると、そこで止まってしまいがちです。<a href="https://aurey.ai/" rel="noopener noreferrer" target="_blank">Aurey AI</a>は、その入口を「作りたいゲームを説明する」という分かりやすい作業に置き換えています。</p><h2>ラフな文章から始められる</h2><p>公開中のStudioを開くと、中央に大きな入力欄があります。雰囲気、物語、ルールを普段の言葉で書けばよく、完成した企画書は求められません。画面には、夕暮れまでに星を集める猫や、庭を育てるワンボタンゲームといった短い例も表示されています。</p><p>この設計は、思いついた内容がまだ曖昧なときに助かります。操作方法や難易度を全部決めてから始めるのではなく、まず動くものを見てから直す考え方です。<a href="https://aurey.ai/studio" rel="noopener noreferrer" target="_blank">AIでゲームを作る画面</a>には「最初のバージョンの後ですべて変更できる」と案内されていました。</p><p>今回確認できたのは、サインイン済みの作成フォーム、サンプル案、作成ボタン、自分のゲーム一覧です。新しいゲームの生成を最後まで実行したわけではないので、生成時間や完成度について体験談のように書くことはできません。入口の分かりやすさは、実際の画面で確認できました。</p><h2>説明を読むより、遊んで判断する</h2><p>トップページでは、会話欄とゲームのプレビューが横に並ぶ使い方が紹介されています。最初のバージョンができたら、ブラウザ上で動かし、ジャンプを軽くしたい、エンディングを変えたい、といった修正を会話で伝える流れです。</p><p>ゲームは、コードが動くだけでは良し悪しを判断できません。移動の速さやタイミングは、触って初めて気づくことが多いからです。Aureyは技術的な出力を前面に出さず、ユーザーが遊び心地に集中できる構成にしています。</p><p>また、公開説明には、プレビュー前の自動チェック、作成者ごとの個別ワークスペース、プレイできる段階ごとの保存が含まれています。失敗した変更から以前の状態へ戻れることは、生成機能そのものと同じくらい実用的です。</p><h2>公開ギャラリーはまだ小さい</h2><p><a href="https://aurey.ai/explore" rel="noopener noreferrer" target="_blank">遊べる作品を見る</a>ページも公開されています。確認時点で掲載されていたゲームは一つでした。現状を大きなマーケットプレイスと呼ぶのは正確ではなく、これから作品が増えていく初期のギャラリーと見るのが自然です。</p><p>Aureyの面白い点は、「AIがゲームを全部作る」という派手な言い方よりも、アイデアを早く試せる形にすることです。文章を書き、遊び、直す。この短い往復がうまく動けば、ゲーム開発経験のない人でも、自分の判断を作品に反映しやすくなります。</p>
]]>
</description>
<link>https://ameblo.jp/nicedayup/entry-12976353212.html</link>
<pubDate>Fri, 21 Aug 2026 10:06:21 +0900</pubDate>
</item>
<item>
<title>DeepSeek Harnessの拡張を導入する前に、ソースを確認する順番</title>
<description>
<![CDATA[ <p>候補を見つける入口として、DSH Hub https://dsh-hub.org/ を使い、リンク先の公開GitHubリポジトリを確認します。&nbsp;</p><p>&nbsp;</p><div class="ogpCard_root"><article class="ogpCard_wrap" contenteditable="false" style="display:inline-block;max-width:100%"><a class="ogpCard_link" data-ogp-card-log="" href="https://dsh-hub.org/" rel="noopener noreferrer" style="display:flex;justify-content:space-between;overflow:hidden;box-sizing:border-box;width:620px;max-width:100%;height:120px;border:1px solid #e2e2e2;border-radius:4px;background-color:#fff;text-decoration:none" target="_blank"><span class="ogpCard_content" style="display:flex;flex-direction:column;overflow:hidden;width:100%;padding:16px"><span class="ogpCard_title" style="-webkit-box-orient:vertical;display:-webkit-box;-webkit-line-clamp:2;max-height:48px;line-height:1.4;font-size:16px;color:#333;text-align:left;font-weight:bold;overflow:hidden">DeepSeek Harness Plugins &amp; Clients | DSH Hub</span><span class="ogpCard_description" style="overflow:hidden;text-overflow:ellipsis;white-space:nowrap;line-height:1.6;margin-top:4px;color:#757575;text-align:left;font-size:12px">Discover verified DeepSeek Harness plugins and clients. Search open-source DSH tools, desktop apps, TUI clients, and extensions with public GitHub repositories.</span><span class="ogpCard_url" style="display:flex;align-items:center;margin-top:auto"><span class="ogpCard_iconWrap" style="position:relative;width:20px;height:20px;flex-shrink:0"><img alt="リンク" class="ogpCard_icon" height="20" loading="lazy" src="https://c.stat100.ameba.jp/ameblo/symbols/v3.20.0/svg/gray/editor_link.svg" style="position:absolute;top:0;bottom:0;right:0;left:0;height:100%;max-height:100%" width="20"></span><span class="ogpCard_urlText" style="overflow:hidden;text-overflow:ellipsis;white-space:nowrap;color:#757575;font-size:12px;text-align:left">dsh-hub.org</span></span></span><span class="ogpCard_imageWrap" style="position:relative;width:120px;height:120px;flex-shrink:0"><img alt="" class="ogpCard_image" data-ogp-card-image="" height="120" loading="lazy" src="https://dsh-hub.org/og-image.png" style="position:absolute;top:50%;left:50%;object-fit:cover;min-height:100%;min-width:100%;transform:translate(-50%,-50%)" width="120"></span></a></article></div><p>&nbsp;</p><p>READMEには対応環境、設定場所、インストールの前提が書かれています。説明が短くても、依存関係の定義、マニフェスト、インストール時のコマンドをたどると、何が追加されるのかをある程度読めます。ライセンス、最近のRelease、Issueも見ておくと、使い始めた後に困ったときの手がかりになります。<br><br>公開リポジトリが読めることは、安全性の保証ではありません。第三者の拡張がローカルのファイル、ネットワーク、シェル、認証情報に触れる可能性は残ります。それでも、出所が分からない配布ページだけで決めるより、根拠を自分で追える状態から始められます。<br><br>プラグインとクライアントは、同じ感覚で扱わない方がよさそうです。プラグインは既存のHarnessプロファイルに機能を足すことが多い一方、クライアントはランタイムや更新経路、複数の拡張、ネットワーク待受をまとめる場合があります。必要な機能から候補を絞ってから、実行範囲を読むと判断しやすくなります。<br><br>初めて使う拡張は、本番用トークンや大切なファイルを入れていない別プロファイルで試します。READMEの設定場所、ライセンス、依存関係、削除手順を確認するだけでも、導入後の驚きは減ります。一度に多くの拡張を足さないことも大切です。問題が起きたときに、原因を戻しやすくなります。<br><br>DSH Hubは候補を探す入口です。そこで見つけた名前を、そのまま信頼する理由にはしません。リンク先のソースを読み、自分の環境で使う理由があるかを確かめてから導入する。私はこの順番の方が、後で悩む時間が少ないと感じています。</p>
]]>
</description>
<link>https://ameblo.jp/nicedayup/entry-12976164690.html</link>
<pubDate>Wed, 19 Aug 2026 09:55:43 +0900</pubDate>
</item>
<item>
<title>A less chaotic way to begin an AI-made website</title>
<description>
<![CDATA[ <p>There is a particular kind of tiredness that arrives after asking an AI tool to make a website. The page appears quickly, which is exciting for about thirty seconds. Then you start looking closely.</p><p>The headline is too grand. The page has four things competing to be the main thing. There are little badges everywhere. The pictures are attractive but do not explain the product. You change one prompt sentence, regenerate, and get a different kind of mess.</p><p>I do not think this means AI builders are useless. I think many of us are asking them to make decisions we have not made ourselves.</p><p>Recently I started using a simpler preparation step. Before I generate anything, I write a few plain sentences about the page: who is arriving, what I want them to notice first, what proof I actually have, and what I would hate to see on the page. It sounds obvious. It has made a real difference.</p><p><a href="https://heydesign.ai/">Hey Design AI</a> is useful in that moment. It is a website-design prompt library built around visual directions and build briefs. Instead of showing a beautiful reference and leaving you to guess why it works, the site describes the choices behind it.</p><h2>The picture is only half the reference</h2><p>The library has 350 visual previews across common website sections and page types. I enjoy looking through them, but I do not treat them as templates. A template encourages you to put your own content inside somebody else’s structure. A brief is more generous. It lets you borrow the logic and change the identity.</p><p>One prompt might show a calm editorial layout. Another may be built around a strong product crop. The useful question is not “which one is prettier?” It is “which one gives my visitor a better chance of understanding the point?”</p><p>That changes the way you browse. You start noticing the message order, the space around the evidence, and the pace of the sections. Those details are easy to miss when you are staring only at colours and corners.</p><h2>I now write down the things I want to avoid</h2><p>My list changes from project to project, but it usually includes a few guardrails: do not invent customer quotes; do not hide the important button on mobile; do not make everything move; do not use a competitor’s personality as a shortcut.</p><p>This kind of instruction is easy to skip because it does not sound creative. In practice, it keeps the result from becoming a collage of familiar AI choices. Hey Design AI includes negative constraints in its prompt guidance, which I appreciate. It feels closer to how a careful designer actually works.</p><h2>A small routine that helps</h2><p>Here is the routine I have settled on. I choose a reference for the job it does, not for the trend it follows. I copy the useful parts of the brief. I replace the generic content with the actual product story. Then I look at the page on a phone before I congratulate myself.</p><p>It is not dramatic, but it is calmer. And the output has a better chance of feeling like it belongs to the product rather than to the AI tool that made it.</p>
]]>
</description>
<link>https://ameblo.jp/nicedayup/entry-12976069060.html</link>
<pubDate>Tue, 18 Aug 2026 09:21:27 +0900</pubDate>
</item>
</channel>
</rss>
